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Alexandria,  VA .  6 


WEDNESDAY,  MARCH  15, 1949-2:00  PM-3:30  PM 
Grand  Ballroom— Salons  A,  B  A  C  (Dennis) 
SESSION  8:  APPLICATIONS 

Chairperson:  Mr.  Brian  Baker,  Navy  Department,  Washington, 
DC 


An  Object-Oriented  Approach  to  Simulating  a  Rea.- 
Time  System  in  Ado— J.  Matgono  and  J.  £.  Walker,  Net¬ 
work  Solutions,  Inc.,  Vienna,  VA .  239 

Ada  Implementation  of  Operating  System  Dependent 
Features— M.  /.  Schwartz  and  R.  W.  Hay,  Martin  Mariet¬ 
ta  Information  &  Communications  Systems,  Denver, 

CO .  245 

Implementation  of  a  Real-Time  Elevator  Control 
Simulation  System  Using  the  Ada  Language— D. 

Begley,  K.  Land,  H.  Tamburro,  and  M.  Vega,  U.S.  Army 
CECOM,  Fort  Monmouth,  NJ .  251 


Grand  Ballroom— Blenheim  Room 

SESSION  9:  PROJECT  MANAGEMENT 

Chairperson:  Ms.  Catherine  Peavy,  Martin  Marietta  Informa¬ 
tion  and  Communication  Systems,  Denver,  CO 


Procurement  of  Air  T raffle  Control  Software  In  Ada— A. 

C.  Chung,  FAA  Technical  Center,  Atlantic  City  Interna¬ 
tional  Airport,  NJ .  257 

The  Use  of  a  Software  Engineering  Exercise  During 
Source  Selection— D.  G  Montgomery,  The  MITRE  Cor¬ 
poration,  FAA  Technical  Center,  Atlantic  City  Interna¬ 
tional  Airport,  NJ .  262 

An  Approach  to  Ada  Compiler  Acceptance  Testing— £. 
Amoroso  and  T.  Nguyen,  AT&T  Bell  Labs,  Whlppany, 

NJ .  266 
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Qanton  Boom*  (tongwood,  Imperial,  Berkshire  &  Tivoli) 

SESSION  10:  TECHNOLOGY  RESEARCH 

Chairperson:  Mr.  Jesse  Williams,  Cheyney  University, 
Cheyney,  PA 

Soltware  Metrics  Analysis  ol  the  Ada  Repository— R.  J. 

Leech,  Howard  University,  Washington,  OC .  270 

Ada  Implementation  ol  Sequential  Correspondent 
Operations  lor  Soltware  Fault  Tolerance— P.  N.  Lee 
and  A.  Tamboll,  University  ol  Houston.  Houston,  TX. . .  278 

Ada— POSIX— T.  Fong,  U.S.  Army  Information  Systems 
Engineering  Command,  Fort  Huachuca,  AZ .  2tU 


WEDNESDAY,  MARCH  15, 1989-2:00  PM-5:00  PM 
Grand  Ballroom  Salon*  A,  B  8  C  (Marlborough) 

SESSION  11:  EDUCATION/TRAINING  , 

Chairperson:  Or.  Murray  Kirch,  Stockton  State  College, 
Pomona,  NJ 


Ada  Summer  Seminar— Teaching  the  Teachers— M.  S. 
Rlchman,  Penn  State  University  ol  Harrisburg,  Mid¬ 
dletown,  PA;  C.  G.  Petersen,  Mississippi  State  Universi¬ 
ty,  MS;  and  D.  C.  ~uhr,  Tuskegee  University,  Tuskegee, 

AL .  288 

Training  COBOL  Programmers  In  Ada— J.  C.  Agrawal, 

Embry  Riddle  Aeronautical  University,  Daytona  Beach, 

FL .  295 

Teaching  Ada  From  the  Outslde-ln— D.  P.  Purdy, 

Manatee  Community  College.  Bradenton,  FL .  303 

An  Intermediate-Level  Problem  Set  lor  Experienced 
Programmers  or  Writing  Ada  Code  that  Achieves  the 
Language  Goals— R.  S.  Rudolph,  Computer  Sciences 

Corp.,  Moorestown,  NJ .  307 

A  10-Day  Ada  Course  lor  the  Industry— F.  Molnlan, 

Cameron  University,  Lawton,  OK . 313 

Integrating  Ada  Training  with  Soltware  Develop- 
mert— P.  Fortin  and  F.  L  Moore,  Texas  Instruments, 

Inc.,  Dallas.  TX .  316 

The  SEI  Education  Program— N.  Gibbs,  Carnegie- 
Mellon  University,  Pittsburgh,  PA  (Invited) 

Evaluation  ol  Teaching  Soltware  Engineering  Re¬ 
quirements  Analysis  (SERA)— J.  Sodhl,  Telos  Federal 
Systems,  Lawton,  OK . 321 


Grand  Ballroom— Blenheim  Room 


SESSION  13:  -.LIFE  CYCLE  MANAGEMENT  . 

•  .  ,  1  ni' 

Chairperson:  Mr.  Walter,  Rolling  Ada  Technology  Group,  Inc., 
Washington,  OC 


The  National  Training  Center  Move  and  Upgrade:  A 
Distributed  Ada  System— 0.  Pottlnger,  Science  Ap¬ 
plications  International  Corp.,  San  Diego,  CA .  358 

Soltware  Quality  Assurance  In  an  Ada  Environ¬ 
ment— S.  Barkatakl,  California  State  University, 
Northridge,  CA;  and  J.  Kelly,  Jet  Propulsion 

Laboratory,  Pasadena,  CA .  362 

Implementing  Soltware  First  with  Today's 
Technology— E.  J.  Gallagher,  Jr.,  U.S.  Army  CECOM, 

Fort  Monmouth,  NJ;  E  Fedchak,  IIT  Research  Institute. 

Rome,  NY;  and  D.  Preston,  IIT  Research  Institute, 

Lanham,  MD .  368 

Lessons  Learned  In  Developing  Requirements— G. 

Healer,  Lockheed  Engineering  &  Sciences  Company, 
Houston,  TX . 383 


Grand  Ballroom— Salons  A,  B  8  C  (Marlborough) 
SESSION  14:  TtEUSE  , 

Chairperson:  Mr.  Oanlel  Hocking,  AIRMICS.  Atlantic.  GA 


Tangram-L— A  Program  Description  Language  (or 
Ada — E.-E.  Doberkat,  University  ol  Essen,  West  Ger¬ 
many  .  390 

AdaL,  An  Automated  Code  Reuse  System— G.  C.  Har¬ 
rison,  Norfolk  State  University,  Norfolk,  VA .  404 

Reusable  Subsystems  from  a  High  Performance  Ada 
Communication  System— T.  L  Chen  and  W.  Sobklw, 
E-Systems,  Inc.,  St.  Petersburg,  FL .  411 


THURSDAY,  MARCH  16, 1989-8:30  AM-12:00  N 

Grand  Ballroom  (Blanhaim  Rooms) 

PANEL  DISCUSSION  III:  *  DoD  SOFTWARE  ENGINEERING 
CONTRACTOR'S  CAPABILITIES  ASSESSMENT  ,  - 

Chairperson:  Miguel  A.  Carrio,  Jr.,  Teledyne  Brown  Engineer¬ 
ing,  Fairfax,  VA 

Panelists: 

Catherine  H.  Peavy,  Martin  Marietta  Information  &  Com¬ 
munications  Systems,  Denver,  CO 
Hal  Hart,  TRW,  Inc.,  Redondo  Beach,  CA 
Barbara  Nash,  GTE  Government  Systems.  Rockville,  MD 
Paul  Mauro,  Hughes  Aircraft  Co.,  Ground  Systems  Group, 
Fullerton,  CA 
(Invited) 


WEDNESDAY,  MARCH  15, 1989-3:45  PM-5:00  PM 
Grand  Ballroom  Salons  A,  B  &  C  (Dennis) 

SESSION  12:  LIFE  CYCLE  ENVIRONMENTS 

k 

Chairperson:  Mr.  Albert  Rodriguez,  U.S.  Army  CECOM, 

Fort  Monmouth,  NJ 


Ada  Abstract  Data  Types— The  Foundation  ol  an  In¬ 
teractive  Ada  Command  Environment— J.  A. 
Thalhamer,  W.  P.  Loltus,  C.  L  Oel,  and  fl.  A.  Foy, 

Unisys  Corp.,  Paoll,  PA .  326 

A  Soltware  Engineering  Documentation  Environ¬ 
ment—  T.  J.  Wheeler,  U.S.  Army  CECOM,  Fort  Mon¬ 
mouth,  NJ .  333 

Documentation  Generation  System— D.  Rodericks,  I. 

Rivera,  B.  Kololske,  R.  Quinones,  U.S.  Army  CECOM, 

Fort  Monmouth,  NJ .  342 

Reducing  Software  Development  Costs  with  Ada— J. 

R.  Carter,  Martin  Marietta  Astronautics  Group,  Denver, 

CO .  348 


Grand  Ballroom— Salons  A,  B  &  C  (Marlborough) 
SESSION  15:  REUSE 

Chairperson:  Ms.  Ruth  Rudolph,  Computer  Sciences  Corp., 


Moorestown,  NJ 

Constructing  Domain-Specific  Ada  Reuse  Libraries— J. 
Solderllsch,  K.  C.  Wallnau,  and  J.  A.  Thalhamer,  Unisys 

Corp.,  Paoll,  PA .  419 

Ada,  Hypertext,  and  Reuse— L.  Latour,  University  ol 

Maine,  Orono,  ME .  434 

Disciplined  Reusable  Ada  Programming  (or  Real-Time 
Applications— F.  Arlco  and  A.  Gargaro,  Computer 

Sciences  Corp.,  Moorestown,  NJ .  443 

The  Morehouse  Object-Oriented  Reuse  Library 
System— A.  M.  Jones  and  R.  Bozeman,  Morehouse  Col¬ 
lege,  Atlanta,  GA .  456 

Reuse  and  the  Soltware  Life  Cycle— D.  S.  Gulndl,  W.  M. 
McCracken,  and  S.  Rugaber,  Georgia  Institute  of 
Technology,  Atlanta,  GA .  463 
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Grand  Ballroom— Salons  A,  B  &  C  (Dannis) 

SESSION  16:  LirE  CYCLE  PRODUCTIVITY 

Chairperson :  Mr.  James  Baibour,  Digital  Equipment  Corpora* 
lion,  Mcrilmac,  NH 


A  Logical  Framework  lot  Version  and  Configuration 
Management  o<  Ada  Components— A.  T,  Jazaa  and  0. 

P.  Braraton,  University  ot  Keete,  Staffordshire.  Great 

Britain .  4G9 

Designing  for  Change;  An  Ada  Design  Tutorial — X  A. 

Hager,  HRB*Systems,  Inc..  State  College.  PA .  475 

A  Portable  Ada  Implementation  of  Blocked_IO— J.  J. 

Cupak,  Jr.,  HRB-Systems.  Inc.,  State  College.  PA .  483 

Developing  a  Universal  Ada  Test  Language  for 
Generating  SoftwareiSystem  Integration  and  Fault 
Isolation  Test  Programs— J.  Ziegler,  J.  M.  Grasso,  L. 
Burgermelster,  and  L  0.  Mollard,  ITT  Avionics,  Nutley, 

NJ .  494 

A  DIANA  Query  Language  for  the  Analysis  of  Ada  Soft¬ 
ware— C.  Byrnes,  The  MITRE  Corp.,  Bedford.  MA .  51 1 

Ada  Portability  Among  Heterogeneous— B.  Casado 
and  N.  Bazzl,  U.S.  Army  CECOM,  Fort  Monmouth,  NJ. .  519 


LUNCH,  12:00  N-2:00  PM 
Ocean  Ballroom— Rooms  A  A  B 


Spotlight  Speaker; 

MG  Peter  A.  Kind,  Program  Executive  Officer,  Army 
Tactical  Command  and  Control  System  (ATCCS),  Fort 

Monmouth,  NJ .  7 

Speaker: 

Dr.  Larry  Drulfel,  Carnegie  Mellon  University,  Director, 
Software  Engineering  Institute,  Pittsburgh.  PA .  8 


THURSDAY,  MARCH  16, 1969-2:00  PM-3:30  PM 

Grand  Ballroom— Blenheim  Rooms 

SESSION  ^TESTING  AND  EVALUATION; 

Chairperson:  CPT  Sheila  Bryant,  Marino  Corps  Tactical 
Systems  Support  Activity,  Camp  Pendleton,  CA 


Ada  Compiler  Validation:  Purpose  and  Practice— R. 
Williams  and  P.  Brashear,  SofTcch,  Inc.,  Fairborn,  OH; 

and  S.  Wilson,  Wrlght-Patterson  AFB,  OH .  522 

How  to  Live  with  TEXT__IO— 0.  W.  Jones,  Ridgecrest, 

CA .  528 

Automatic  Test  Data  Generation  and  Assertion  Testing 
for  Ada  Program  Units— L.  Mayes,  R.  W.  Aragon,  D.  Ter- 
rlen,  and  J.  Trost,  Intermetrics,  Inc.,  Hunti-.^ton  Beach, 

CA .  537 


Grand  Ballroom— Salons  A,  B  A  C  (Marlborough) 

SESSION  18:  DESIGNING  FOR  ADA 

Chairperson :  Or.  Ronald  Leach,  Howard  University, 
Washington,  DC 

Practical  Advice  for  Designing  Ada  System  Architec¬ 
tures— C.  D.  Bachman,  Allied-Signal  Aerospace  Co., 

Teterboro,  NJ .  549 

Ada  Design  Tool— K.  Tuppar,  M.  Levliz,  J.  Helzron,  S. 

Bariev,  and  P.  Davarzo,  Unisys  S&GSG.  Great  Neck,  NY  557 

Objects  with  Multiple  Representations  In  Ada— K.  M. 

George,  Oklahoma  State  University,  Stillwater,  OK;  and 
J.  Sodhl,  Telos  Federal  Systems,  Lawton,  OK .  567 


Grand  Ballroom— Salons  A,  B  A  C  (Dannis) 
SESSION  19:  LIFE  CYCLE  PRODUCTIVITY 
Chairperson:  Ms.  Susan  Market,  TRW,  Fairfax,  VA 

A  Software  Development  Tool  Using  Ada— Pseudo 
Code  Management  System— D.  Blau  Uu,  California 

State  University— Long  Beach,  Long  Beach,  CA .  576 

Data  Reduction:  An  Ada  Generics  Methods— W.  D. 
Ferguson,  C.  L  Carrulhers,  B.  J.  Carter,  Jr.,  K.  A. 
Staples,  Jr.,  and  C.  P.  Wise,  General  Electric  Corp., 

ESD,  Moorestown,  NJ .  584 

A  Method  of  Translating  Functional  Requirements  for 
Object-Oriented  Design— R.  Brown  and  V.  Dobbs, 

Wright  State  University,  Dayton,  OH .  589 


THURSDAY,  MARCH  16, 1989-3:45  PM-5:45  PM 
Grand  Ballroom  (Blanhaim  Rooms) 

PANEL  DISCUSSION  IV:  LOOKING  TO  THE  FUTURE 
WITH  ADA.  /}/.  */.. ,  V"  *'•  - 

Chairperson:  Miguel  A.  Carrio,  Jr.,  Teledyne  Brown  Engineer¬ 
ing,  Fairfax,  VA 

Panelists:  .  .  *  . 

Jean  Ichblah,  Alsys,  Inc.,  Waltham.  MA  j\ 

Charles  McKay,  University  of  Houston-Clearlake,  Houston,  ) 

TX 

Frank  Belz,  TRW,  Inc.,  Redondo  Beach,  CA 

Howard  Yudkln,  Software  Productivity  Consortium,  Reston,  ' 

VA 

(Invitee) 
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OPENING  PANEL 


ADA  POLICY,  PRACTICES  AND  INITIATIVES 


Mr.  James  E.  Schell 
President 

SOPHSYS,  Incorporated 
(Moderator) 


LTG  Bruce  R.  Harris 

Director  of  Information  Systems  for  C4 
Office  of  the  Secretary  of  the  Army 
Washington ,  DC 


James  E.  Schell  is  the  former  Director  of 
the  CECOM  Center  for  Software  Engineering. 
He  retired  from  the  U.S.  Civil  Service  as  a 
Senior  Executive  (SES)  in  March  1988.  He  holds 
a  Baccalaureate  Degree  in  Mathematics,  Physics, 
and  French  from  Morehouse  College,  Atlanta, 
Georgia.  He  has  studied  graduate  work  in  the 
MBA  program  and  Anthropology  nt  California  State 
University,  Northrldgc,  California  and  completed 
several  executive  development  courses  at  the 
University  of  California,  Berkeley  and  the 
University  of  Southern  California. 

He  has  had  an  extensive  and  rewarding  career 
in  both  government  and  industry.  He  has  held 
training  positions  with  the  Air  Force  and  Army 
Signal  Corps;  a  Soldier  in  the  Signal  Corps; 
Signal  Publications;  a  charter  member  of  Command 
Control  Information  Systems  in  1970  (CCIS-70) 

Project  Manager's  Office.  From  there,  he  held 
positions  in  Litton  Data  Systems  Division  as 
Director  of  the  AN/TTC-39  Program  Office  and 
Director  of  the  TACFIRE/TOS  Program  Office. 

He  returned  to  Government  in  1979  in  the 
Senior  Executive  Service  as  Director,  U.S.  Army 
Center  for  Tactical  Computer  Systems  (CENTACS) 
during  which  time  he  founded  this  Ada  Technology 
Confernecc.  Mr.  Schell  culminated  his  government 
career  by  serving  as  the  Deputy  Program  Manager, 
Army  Command  and  Control  System  from  1985  to 
1986  and  as  Director  Center  for  Software 
Engineering  from  1986  to  1988. 

He  now  has  his  own  consultancy  as  SOPHSYS, 
Inc.  He  and  his  wife,  the  former  Doris  Hunter, 
live  in  Ocean  Township,  New  Jersey. 


Lieutenant  General  Bruce  R.  Harris  was  born 
in  Sullivan  County,  Indiana  on  13  August  1934. 
Upon  completion  of  the  Reserve  Officers  Trainin'- 
Corps  curriculum  and  the  educational  course 
of  study  at  Tennessee  Technological  University 
in  1956,  he  was  commissioned  a  second  lieutenant 
and  awarded  a  Bachelor  of  Science  degree  in 
Business.  He  also  holds  a  Master  of  Science 
degree  in  Political  Science  from  Auburn 
University.  His  military  education  includes 
completion  of  the  Signal  Officer  Basic  am' 
Advanced  Courses,  the  United  States  Army  Commanc 
and  General  Staff  College,  and  the  Air  War 
College . 

He  has  held  a  wide  variety  of  command  and 
Btaff  positions  culminating  in  his  current 
assignment  as  Director  of  Information  Systems 
for  C4,  Office  Secretary  of  the  Army.  These 
include  command  of  the  13th  Signal  Battalion, 
1st  Cavalry  Division;  command  of  the  Division 
Support  Command,  2d  Armored  Division;  Chief 
of  Staff  and  later  Deputy  Commandant  of  the 
U.S,  Army  Signal  School;  Deputy  Assistant 
Secretary  of  Defense  for  Legislative  Affairs; 
Assistant  Division  Commander,  9th  Infantry 
Division;  command  of  the  U.S.  Army  Communications 
Electronics  Engineering  Installation  Agency; 
Deputy  Commander,  U.S.  Army  Information  Systems 
Command;  and  command  of  the  U.S.  Army  Signal 
School . 

Awards  and  decorations  which  General  Harris 
has  received  include  the  Distinguished  Service 
Medal,  Legion  of  Merit,  the  Bronze  Star  Medal, 
the  Meritorious  Service  Medical  (with  Oak  Leaf 
Cluster),  several  Air  Medals  and  the  Army 
Commendation  Medal.  He  alBO  wears  the  Parachutist 
Badge  and  the  Master  Army  Aviator  Badge. 

lie  Ib  married  to  the  former  Claudia  Alley 
and  they  have  four  children!  Bruce,  Jr.,  Mary 
Kathryn  Brooks,  Tim,  and  Brad. 
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OPENINC  PANEL 


ADA  POLICY,  PRACTICES  AND  INITIATIVES 


LTG  Gordon  E.  Pornell 
Commander  Electronics  Systems  Division 
U.S.  Air  Force  Systems  Command 
Hanscom  Air  Force  Base,  MA 

Lieutenant  General  Cordon  E.  Fornell  is 
commander  of  Electronic  Systems  Division,  Air 
Force  Systems  Command,  Hanscom  Air  Force  Base, 
Massachusetts . 

General  Fornell  was  born  on  18  September 
1936,  in  Chicago  and  graduated  from  Maine  Township 
High  School,  Des  Plaines,  Illinois.,  in  1954. 
lie  received  a  Bachelor  of  Science  degree  in 
Mechanical  Engineering  from  Michigan  State 
University  in  1958  and  a  Master  of  Business 

Administration  degree  from  the  Wharton  School, 
University  of  Pennsylvania,  in  1978.  While 

at  Michigan  State  University,  the  general  was 
a  member  of  the  1957  Big  Ten  Conference 

championship  swim  team.  He  completed  Squadron 
Officer  School  in  1963  and  Air  War  College  in 
1973. 

He  was  commissioned  as  a  second  lieutenant 
through  the  Air  Force  Reserve  Officer  Training 
Corps  program  and  entered  active  duty  in  October 
1958.  He  received  his  initial  pilot  training 
at  Moore  Air  Base,  Texas,  and  Greenville  Air 

Force  Base,  Mississippi,  from  November  1958 
to  November  1959.  In  June  1960  he  completed 
F-86L  fighter- interceptor  training  at  Perrin 
Air  Force  Base,  Texas. 

Upon  graduation  from  Air  War  College  in 
June  1973,  the  general  was  assigned  to 
Headquarters,  U.S.  Air  Force,  Washington,  D.C., 
as  chief,  Aeronautical  Systems  Division, 
Directorate  of  Development  and  Acquisition, 
until  January  1977.  In  this  capacity  he  was 
responsible  for  most  of  the  aircraft  development 
programs,  including  the  F-15,  B-l,  F-16  and 
A-10,  and  for  technology  based  programs  involving 
aircraft  equipment,  life  support  and  turbine 
engines . 


General  Fornell  returned  to  the  Pentagon 
in  July  1981  as  Deputy  Director  of  Development 
and  Production  on  the  Air  Staff  and  was 
responsible  for  programs  that  included  aircraft, 
propulsion,  avionics,  armament  and  electronic 
combat  systems. 

In  October  1982,  General  Fornell  became 
special  assistant  for  intercontinental  ballistic 
missile  modernization  matters.  Office  of  the 
Deputy  Chief  of  Staff  for  Research,  Development 
and  Acquisition,  at  Air  Force  Headquarters. 
He  became  the  Senior  Military  Assistant  to  the 
Secretary  of  Defense  in  January  1987.  In  that 
position  he  assisted  and  advised  the  secretary 
on  the  full  range  of  defense  responsibilities 
and  national  security  .  matters .  He  assumed  his 
present  command  in  September  1988. 

His  military  decorations  and  awards  include 
the  Defense  Distinguished  Service  Medal, 
Distinguished  Service  Medal,  Legion  of  Merit 
(with  one  Oak  Leaf  Cluster),  Distinguished  Flying 
Cross  (with  two  Oak  Leaf  Clusters),  Meritorious 
Service  Medal  (with  one  Oak  Leaf  Cluster),  Air 
Medal  (with  11  Oak  Leaf  Clusters),  and  Air  Force 
Commendation  Medal.  He  also  wears  the  Basic 
Parachutist  Badge  and  the  Missile  Crew  Member 
Badge . 

He  was  promoted  to  lieutenant  general  1 
October  1988,  with  same  date  of  rank. 

General  Fornell  is  married  to  the  former 
Barbara  A.  Bauer  of  LaGrange  Park,  Illinois. 
They  have  two  children  Kirsten  and  Eric. 
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am  polict,  rsACTiCM  ado  miTiATtm 


RAOH  Paul  K.  Tallin  Jr. 

Director  of  IU vy  hioarcti  N«u|««nil 
Office  of  [lx  Assistant  Stenurjf 
of  the  Ravjr  for  PimaorJat  Management 
UukliiittMi,  DC 

(tear  Adalral  Paul  E.  Tobin,  Jr.  vat  graduated 
fro*  the  U.S.  Kauai  Academy  In  1963  and  reported 
to  the  USS  Tower*  where  he  served  at  First 
Lieutenant  and  Main  Propulsion  Assistant.  In 
19(iB ,  Admiral  Tobin  vat  avarded  a  Matters  of 
Science  degree  In  Cooputer  Systems  Management 
frOM  the  Kauai  Pott  Craduate  School.  He  vat 
graduated  with  distinction  by  the  Kaval  Uar 
College  from  the  Kaval  Conaand  and  Staff  Course. 
Ke  vat  alto  graduated  with  distinction  froa 
the  Industrial  College  of  the  Aracd  Forces  in 
1984. 

Adalral  Tobin  has  held  a  nuaber  of  Command 
assignments  among  then  the  USS  TATTKALL  In  the 
Indian  Ocean  and  the  Persian  Culfi  the  USS  FOX 
deployed  to  the  Indian  and  the  Western  Pacific) 
he  alto  attuned  coma  ml  of  the  Surface  Warfare 
Officers  School  Coamand  In  July  1986.  ills  awards 
and  decorations  Include  the  Bronte  Scar,  the 
Meritorious  Service  Medal  and  the  Kavy 
Commendation  Medal  (with  two  Cold  Scars). 

Admiral  Tobin  is  currently  assigned  at 
Director,  Department  of  the  Kavy  Information 
Resources  Management,  he  alto  serves  at  Director, 
Information  Management  Support  Division  under 
the  cognisance  of  the  Chief  of  Kaval  Operations. 

Adalral  Tobin  la  curried  to  the  former  Lynne 
Carter  of  Shaker  Heights,  Ohio.  They  have  two 
daughcerti  Mary  Elisabeth  and  Patricia. 


Dr.  R.E.  Lyom  (SXS) 

Acting  Associate  Director  for 
Engineering  and  Technology, 

Defense  fnasmiaicatloma  Agency 
Arlington,  VA 

Dr.  Lyon  received  the  Bachelor  of  Science 
Degree  In  Electrical  Engineering  from  MIT  In 
1930.  Hit  graduate  degrees  Include  the  MS  and 
PhD  degree*  In  Electrical  Engineering  from  the 
University  of  Maryland,  and  the  professional 
Electrical  Engineers  degree  from  MIT. 

Dr.  Lyon  Is  Acting  Associate  Director  for 
Engineering  and  Technology,  Defense  Communication* 
Agency.  Among  his  other  duties,  he  is  the  DCA 
Ada  Executive.  Ills  office  1*  the  interface 
between  DCA  and  the  world  of  high  technology 
In  government.  Industry  and  academia,  and  has 
the  responsibility  to  promote  the  transition 
of  high  technology  to  operational  use  In  the 
C3  community.  Formerly  Special  Assistant  to 
the  Director,  Information  Processing  Techniques 
Office,  DARPA,  and  Deputy  Director,  Defense 
Communications  Engineering  Center,  DCA,  Dr. 
Lyon  hat  been  Involved  in  systems  engineering 
of  U.S.  C3  systems  since  1970.  He  ha*  39  years 
of  professional  experience  In  DoD  Information 
and  communications  systems  and  has  previously 
held  position  with  the  IBM  Corporation  and 
Katlonal  Security  Agency. 

He  is  a  senior  member  of  the  IEEE,  a  Covernor 
of  the  International  Council  for  Computer 
Communications,  a  member  of  the  Armed  Forces 
Communications  and  Electronics  Association, 
and  a  recipient  of  the  Defense  Communications 
Agency  Director's  Exceptional  Civilian  Service 
and  Distinguished  Executive  Awards. 
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SC  John  0.  Wakelia 

Deputy  Director,  Unified  and  Specified 
Co— sod  C*  Support 

Or|M(Mllw  of  Omi  Joint  Chief*  of  Staff 
Washington,  SC 


Brigadier  Central  John  E.  Vakclln  vat  born 
in  San  Francisco,  California  on  12  January 
1936.  Upon  coapletlon  of  the  Reserve  Officer* 
Training  Corp*  currlculun  and  the  educational 
course  of  *tudy  at  the  University  of  San 
Francisco  in  1959  he  va*  cosnlss toned  a  second 
lieutenant  and  awarded  a  Bachelor  of  Science 
degree  in  Philosophy.  His  Military  education 
includes  coapletion  of  the  Sasic  Signal  Officer 
Course,  the  Infantry  Advanced  Oftlcer  Course, 
the  United  States  Army  Coooand  and  General 
Staff  College,  and  the  National  War  College. 

He  has  held  a  wide  variety  of  Important 
command  and  staff  positions  culminating  in 
his  current  assignment.  Immediately  prior 
he  served  as  Deputy  Commander  for  Research 
and  Development  at  the  Communications  Electronic* 
Coawand,  Fort  Monmouth,  New  Jersey.  Other 
key  assignaents  held  recently  Include  Commander 
of  the  35th  Signal  Brigade  at  f,rt  Bragg,  North 
Carolina  and  Special  Assistant  to  the  Commanding 
Ceneral  of  the  Communication*  Electronics 
Command,  Fort  Monmouth,  New  Jersey. 

Ceneral  Uakelin  has  an  extensive  background 
in  the  management  of  communications  and  signal 
resources.  Following  overseas  service  as  Chief 
of  Communications  Electronics  with  the  United 
States  Defense  Liaison  Croup  in  Indonesia, 
he  commanded  the  50th  Signal  Battalion  (Airborne} 
at  Fort  Bragg,  North  Carolina.  Ceneral  WakcUr. 
then  served  as  Deputy  Commander  for  the 
battalion's  parent  35th  Signal  Croup.  Following 
completion  at  the  National  War  College,  he 
served  as  Deputy  Director  for  Command,  Control 
and  Communications  with  the  Defense 
Communications  Agency,  Washington,  DC. 


Awards  and  decorations  which  Ceneral  Wakelin 
hat  received  include  the  Bronze  Scar  Medal, 
the  Meritorious  Service  Medal  (with  Oak  Leaf 
Clustttr),  and  the  Joint  Service  Commendation 
Medal.  Ke  also  hold*  the  Army  Co— endaclon 
Medal  (with  Oak  Leaf  Clutter)  and  is  authorized 
to  wear  the  Parachutist  Badge. 

Me  and  his  wife  Janls  (Jan)  have  five 
children!  John,  Jennifer,  Jeffrey,  Heather, 
and  Jaclyn. 
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HC  Killy  X.  Th<xM« 

Cn— mi4  Ccneral 

U.S.  Army  Commainlcationa-Kleelronie*  Command 
Fort  Monmouth ,  KJ 


Mr.  Joacph  M.  Dal  Ralxo 
Executive  Director  for  System 
Development,  PAA 
Washington,  DC 


Major  General  Killy  M.  Thomas  was  Dorn  in 
Crystal  City,  Texas  on  U  August  1940.  lie  grew 
up  in  Klleen,  Texas.  Upon  completion  of  the 
Reserve  Officer's  Training  Corps  curriculum 
and  the  educational  course  of  study  at  Texas 
Christian  University  in  1962,  he  was  commissioned 
a  second  lieutenant  In  the  U.S.  Army  and  was 
awarded  a  Bachelor  of  Seienee  degree  in  Secondary 
Education.  Ccneral  Thomas  holds  a  Master  of 
Science  degree  in  Telecommunication*  Operations 
from  Cocrge  Washington  University. 

Ms  military  education  Includes  completion 
of  the  Signal  Officer  Basic  and  Advanced  Courses, 
the  Army  Command  and  Ccneral  Staff  College, 
and  the' Army  War  College. 

In  addition  to  General  Thomas'  many  important 
command  assignments  in  Germany,  Thailand,  and 
Vietnam,  he  has  also  held  a  variety  of  significant 
staff  assignmenta  prior  to  his  assuming  the 
position  of  Commanding  General,  U.S.  Army 
Coccunirac Iona-Elect  rentes  Command,  among  them 
verei  Special  Assistant  to  the  Dean,  National 
Defenae  University!  Deputy  Commanding  General, 
U.S.  Army  Signal  Center  and  School)  Army  Staff 
as  the  Deputy  Director)  Combat  Support  Systems, 
Office  of  the  Deputy  Chief  of  Staff  for  Research, 
Development  and  Acquisition. 

Awards  and  decorations  which  Ccneral  Thomas 
has  received  Include  the  Legion  of  Merit,  Bronze 
Star  Medal,  the  Meritorious  Service  Medal  and 
the  Army  Commendation  Medal.  Me  is  also 
authorized  to  wear  the  Parachutist's  Badge. 

Me  is  married  to  the  former  Judith  K. 
McConnell  of  Boise,  Idaho.  They  have  four 
children!  Jon,  Kin,  Kirsten,  and  David. 


As  PAA's  Executive  Director  for  System 
Development,  Joseph  H.  Del  Balzo  Is  one  of  four 
Executive  Directors  who  assist  the  FAA  Admin¬ 
istrator  In  setting  agency  policy  and  governing 
the  development  and  accomplishment  of  agency 
programs. 

Mr.  Del  Balzo  Is  responsible  for  National 
Airspace  System  Development,  Advanced  Design 
and  Management  Control,  Airport  System 
Development,  and  PAA's  Technical  Center  in  Pomona, 
New  Jersey. 

Mr.  Del  Balzo  was  Director  of  PAA’s  Eastern 
Region  from  November  1981  to  July  1987.  As 
Director  of  the  Eastern  Region,  Mr.  Del  Balzo 
was  responsible  for  all  FAA  activities  within 
seven  states  (New  York,  New  Jersey,  Pennsylvania, 
Delaware,  Maryland,  Virginia,  and  West  Virginia) 
and  the  District  of  Columbia. 

Mr.  Del  Balzo  was  Director  of  the  FAA 
Technical  Center  from  January  1979  to  November 
1981.  Me  previously  served  as  the  Technical 
Center  Deputy  Director.  Me  was  Chief  of  the 
Microwave  Landing  System  (MLS)  Division  of  the 
Systems  Research  and  Development  Service.  Me 
was  responsible  for  the  successful  development 
and  xelzetion  of  the  U.S.  design  of  the  MLS. 

Mr.  Del  Balzo  began  his  Federal  career  in 
1998  as  an  Electrical  Engineer  in  Portland  Maine. 
Me  holds  a  B.S.  in  Electrical  Engineering  from 
Manhattan  College,  and  an  M.S.  in  Engineering 
Management  from  Drexel  University.  In  1975, 
on  a  one-year  fellowship  to  Princeton  University, 
he  studied  public  policy  and  international 
affairs.  Me  vas  awarded  an  Honorary  Doctoral 
degree  in  Aeronautical  Science  by  Enbry-Rlddle 
Aeronautical  University  ?n  August  1981.  Mo 
is  a  general  aviation  enthusiast  and  is  an 
instrumentrated,  multi-engine  private  pilot. 
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LTC  Jtrrj  Hoc  B— yard 
Softly  Co— dim  Ceamral 
Research  Develop— ml  —d  Acquisition 
USAMC,  Alexandria,  VA 


Brigadier  Central  John  A.  Hedrick  was  horn 
in  Houston,  Texas  on  24  January  19*1 «  After 
completion  of  the  Reserve  Officers  Training 
Corps  curriculum,  he  was  co—iss toned  a  second 
lieutenant  on  6  Kovember  1964  and  awarded  the 
Bachelor  of  Science  degree  in  Electrical 
Engineering  at  Texas  A4M  University.  He  also 
holds  a  Hatters  of  Business  Administration  degree 
in  Operations  Research  and  Systems  Analysis 
fro*  Tulane  University.  His  Military  education 
includes  completion  of  the  Signal  Officer  Raslc 
and  the  Armor  Officer  Courses,  the  Radio  Officer 
Course,  the  U.S.  Army  Co— and  and  Ceneral  Staff 
College,  and  the  U.S.  Air  Force  War  College. 

He  has  held  a  wide  variety  of  laportant 
co— and  and  staff  positions  culainatlng  in  his 
present  assignment.  Following  his  assignment 
as  Operations  Officer  in  the  9th  Signal  Battalion, 
he  served  as  communications  Staff  Officer, 
Xatlonal  Communications  System)  Chief, 
Congressional  Inquiry  Division)  Office  of  the 
Chief  of  Legislative  Liaison)  Deputy  Commander, 
1st  Signal  Krlgade,  Aray  Communications  Agency 
Korea)  Training  and  Doctrine  System  Manager, 
Aray  Tactical  Communications  System)  Deputy 
Director  for  Flans,  Frograas  and  Systeai  Office 
of  the  Director  of  Information  Systems  for  C4| 
Office  of  the  Secretary  of  the  Army,  Washington, 
DC. 

His  military  decorations  and  awards  Include 
the  Legion  of  Merit  and  the  Bronxe  Star  (each 
with  two  Oak  Leaf  Clusters),  the  Defense 
Meritorious  Service  Medal  and  the  Army  Meritor¬ 
ious  Service  Medal  (with  three  Oak  Leaf  Clusters), 
and  Aray  Co— endation  Medal,  and  the  Army  Ceneral 
Staff  Identification  Badge. 

Ceneral  Hedrick  is  married  to  the  former 
Katherine  Crain  of  Childress,  Texas;  they  have 
three  daughters i  Janell,  Janet  and  Jo  Anne. 


Lieutenant  Ceneral  Jerry  Max  Runyard  was 
horn  in  Altus,  Oklahoma  on  2  April  1931.  Upon 
completion  of  the  Reserve  Officers  training 
Corps  Course  curriculum  and  the  educational 
course  of  study  in  1954,  he  was  eo—  ixatoned 
a  second  lieutenant  and  awarded  a  Bachelor  of 
Science  degree  in  Animal  Husbandry.  He  also 
holds  the  Master  of  Science  degree  in  Inter¬ 
national  Relations  from  George  Washington 
University.  Mis  military  education  includes 
completion  of  the  Infantry  Officer  Basic  course, 
the  Field  Artillery  Officer  Advanced  Course, 
the  U.S.  Aray  Command  and  Ceneral  Staff  College, 
and  the  Rational  War  College. 

He  has  held  a  variety  of  important  eo— and 
And  staff  positions  culminating  in  his  current 
assignment  as  Deputy  Commanding  Ceneral,  Research, 
Development,  and  Acquisition)  U.S.  Army  Materiel 
Command.  Other  key  assignments  held  recently 
include  Assistant  Deputy  Chief  of  Staff  for 
Research,  Development,  and  Acquisition)  Project 
Manager  for  the  Tactical  Fire  Direction 
Systea/Field  Artillery  Tactical  Data  Systems) 
Deputy  Director  for  Defense  Test  and  Engineering) 
Project  Manager,  PATRIOT  Air  Defense  Hlssile 
Systems)  and  Co— andlng  Ceneral  U.S.  Army  Missile 
Co— and  and  Redstone  Arsenal,  Alabama. 

Among  his  command  assignments  are  the  2d 
Battalion,  20th  Artillery,  1st  Cavalry  Division, 
Vietnam,  Chief,  Technical  Support  U.S.  Army 
Operational  Test  and  Evaluation  Agency,  and 
Commander,  Yuma  Proving  Cround,  Arizona. 

His  awards  and  decorations  include  the  Defense 
Superior  Service  Medal,  The  Legion  of  Meric, 
the  Distinguished  Flying  Cross  (with  Oak  Leaf 
Cluster),  the  Bronze  Star  Medal  (with  two  Oak 
Leaf  Clusters),  the  Meritorious  Service  Medal 
(with  two  Oak  Leaf  Clusters),  several  Air  Medals, 
the  Joint  Service  Com—ndacion  Medal,  the  Master 
Army  Aviator  Badge,  the  Office  Of  the  Secretary 
of  Defense  Identification  Badge. 

He  is  married  to  the  former  Celia  Wllkerson; 
they  have  two  children!  Mike  and  Brenda. 
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>{A  Jor  General  Peter  A.  Kind  is  A  native 
of  Wisconsin.  Upon  couplet  ion  of  studies  at 

the  University  of  Wisconsin  in  1961,  he  was 
commissioned  s  Second  Lieutenant  and  awarded 
a  Sachelot  of  Science  degree  in  Economics. 
He  also  holds  a  Master  of  Business  Administration 
fro*  Harvard  University.  His  military  education 
includes  che  laslc  Officer  Course  at  the  Signal 
School,  the  Coenunications  Officer  Course  offered 
at  the  U.S.  Marine  Corps  Amphihious  Warfare 

School,  the  U.S.  Army  Command  and  Central  Staff 
College  and  the  U.S.  Amy  War  College. 

He  was  assigned  to  the  97th  Signal  Battalion 
(Army),  10th  Special  Forces  Croup  (Airborne) 

in  Germany  and  as  Signal  Advisor  to  the  21st 
Infantry  Division  (Air  Assault)  In  Vietnam. 

Following  duty  as  Assistant  Division  Signal 
Officer  of  the  Sid  Airborne  Division  and  as 
Executive  Officer  and  S2/53 

( Intel lignnee/Operat Ions  and  Training)  for 

the  83d  Signal  Battalion,  Fort  Bragg,  Korth 
Carolina,  he  served  in  the  War  Flans  Division 
of  the  Office  of  the  Deputy  Chief  of  Staff  for 
Operations  and  Flans,  Headquarters,  Department 
of  the  Army.  He  commanded  (he  1st  Cavalry 

Division's  13th  Signal  Battalion,  Fore  Hood, 
Texas  and  studied  at  the  Logistics  Management 
Center's  School  of  Management  Science.  Ceneral 
Kind  then  served  as  Chief  of  the  Concepts  and 
Studies  Division,  Directorate  of  Combat 
Developments  at  the  Signal  Center  prior  to  Army 
War  College  attendance. 

He  then  served  as  Comander  of  the  1st  Signal 
Brigada  with  concurrent  duty  os  che  Assistant 
Chief  of  Staff,  J6,  U.S.  Forces  in  Korea  and 
C-6,  Eighth  U.S.  Army;  as  Director  of  Combat 
Development,  and  as  Deputy  Commanding  Ceneral 


and  Assistant  Commandant,  U.S.  Army  Signal  Center 
and  School,  Uorc  Cordon,  Georgia.  He  served 
as  Deputy  Controller  of  the  MATO  Integrated 
Communications  Uystem  Central  Operating  Authority, 
MATO's  equivalent  to  the  U.S.  Defense  Communi¬ 
cations  Systems,  headquartered  at  SKATE,  Belgium, 
prior  to  hla  appointment  as  Frogram  Executive 
Officer,  Command  and  Control  Systems. 

Ceneral  Kind  has  been  awarded  the  Legion 
of  Merit,  the  Bronte  Scar  Medal  (with  two  Oak 
Leaf  Clusters),  and  the  Meritorious  Service 
Medal  (with  two  Oak  Leaf  Clusters).  He  Is  also 
the  recipient  of  the  Air  Medal  with  two  device 
and  the  Army  Commendation  Medal,  the  Senior 
Parachutist  Bsdge  and  the  Army  Ceneral  Staff 
Identification  Badge. 

He  is  married  to  the  former  Sandra  L.  Hanson. 
They  have  a  son,  Lee. 
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Dr.  Larry  Druffel 
Carnegie  Mellon  University 
Director,  Software  Engineering  Institute 
Pittsburgh,  M 


Larry  C.  Druffel  Is  director  of  the  Software 
Engineering  Institute.  Appointed  to  that  position 
Ir.  September  1986,  he  wee  previously  Vice 
President  for  business  development  at  national, 
a  company  that  provides  advanced  software 
development  technologies. 

Oruffel  has  been  associated  with  the  Ada  program 
since  1978.  lie  was  a  member  of  the  High  Order 
language  Working  Croup,  and  became  the  first 
Director  of  the  Ada  Joint  Program  Office.  He 
was  later  appointed  Director  of  Computer  Systems 
and  Software  In  the  Office  of  the  Secretary 
of  Defense  (Research  and  Advanced  Technology), 
a  position  that  Included  management  responsibility 
for  the  Ada  program.  He  defined 
computertechnology  research  strategies,  was 
the  Initial  Architect  of  the  STARS  program, 
and  proposed  the  Software  Engineering  Institute. 

Druffel,  who  was  Associate  Professor  and 
Deputy  Director  of  the  Department  of  Computer 
Science  at  the  United  States  Air  Force  Academy, 
has  managed  research  programs  in  advanced  software 
technnlogy,  artificial  Intelligence,  and  G)1 
at  the  Defense  Advanced  Research  Projects  Agency. 

In  addition  to  being  coauthor  of  a  computer 
science  textbook  and  of  more  than  70  professional 
papers,  Druffel  it-  also  a  aofrware/Ada  editor 
for  Defense  Science  and  Elecironlcs.  He  holds 
a  Bachelor's  degree  In  Electrical  Engineering 
from  the  University  of  London,  and  a  Doctorate 
in  Computer  Science  from  Vanderbilt  University. 
He  is  a  senior  <aceber  of  7EEE  and  a  member  of 
the  Association  for  Computing  Machinery. 


Donald  J.  Herman 
Organising  Chairman 
UHIX  International 


Hr.  Donald  J.  Herman  has  been  the  Organising 
Chairman  of  t'RIX  International  since  Koveaber 
1988.  Prior  to  this  appointment,  he  served 
for  10  years  with  KCR  Corporation  of  Dayton, 
Ohio  and  most  recently  os  the  Executive  Vice 
President  In  the  Office  of  the  Chief  Executive 
with  responsibility  for  the  company's  Integrated 
business  units. 

He  holds  a  Bachelor's  degree  in  Industrial 
Engineering  from  the  University  of  South  Dakota; 
he  served  as  a  Haval  Officer  from  19M  to  I960 
So  the  Rational  Security  Agency. 

In  1962,  he  was  a  founder  of  COMRESS,  a 
highly  successful  software  development  and  leasing 
firm.  During  his  tenure  as  Its  Chairman  and 
Chief  Executive  Officer,  COMKESS  founded  four 
other  computer  related  companies,  one  of  which 
was  COMTEK,  a  computer  communications  company; 
Mr.  Herman  assumed  active  management  of  COMTEK 
which  subsequently  acquired  COMKESS. 

In  1979,  NCR  acquired  COMTEK  and  appoinred 
Mr.  Herman  as  the  President  and  Chief  Executive 
Officer  of  the  Independent  operating  Subsidiary, 
KCR  COMTEK.  Mr.  Herman  was  later  appointed 
a  Vlee  President  of  KCR  Corporation  and  went 
on  to  be  named  Chairman,  KCR  COMTEK,  and  was 
appointed  Executive  Vice  President  of  KCR 
Corporation. 

In  1989,  while  at  KCR,  he  became  the  founding 
Chairman  for  the  Corporation  foe  Open  Systems 
(COS).  COS  was  one  of  the  computer  industry's 
first  open  systems  consortia,  and  was  primarily 
concerned  with  establishing  the  Open  System 
Reference  Model  as  a  industry  standard. 

Don  Herman's  experience  with  high  technology 
companies  spans  more  chan  26  years. 
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Stephen  R.  Mackey 


Locknccd  Missiles  &  Space  Coa$any 
Austin.  Texas 


Today,  the  tactical  reaaarsder  Is  confronted  with  a 
high  technology  battlefield  that  has  significantly 
increased  In  complexity.  speed.  and  diversity 
Automated  decision  aids  can  drastically  reduce  the 
ilM  required  lor  decision-making  processes 
necessary  for  planning  coabat  operation*  C-ns  hey 
preblea  associated  with  such  decision  Aid*  is 
developing  »eihod*  10  eapley  cosily  *nd  scarce 
combat  resources  efficiently  end  effectively 
Upgrading  current  tactical  comdL  control. 
ceeaunlcaUens,  And  intelligence  (CJU  system*  or 
the  fielding  of  new  CJI  systems  wsrrAnts  the 
application  of  this  technology.  By  cresting 
Ada-based  prototype  decision  *ld  technology, 
development  tine  And  costs  for  emerging  Cll  systems 
can  be  significantly  reduced  The  RAUCRa  software 
Is  a  decision  Aid  consisting  of  reussble  components 
that  optimise*  the  allocation  of  specific  resources 
tweapensi  against  selected  requirement*  ttArgetsi 
for  a  tAetlCAl  scenario 


S'i'grvirx 

The  Reusable  Ads  Modules  for  Optimal  Resource 
Allocation  iRAUQKAi  system  w»*  developed  under 
contract  to  the  Naval  Research  laboratory  (MRU  a., 
part  of  the  software  Technology  for  Adaptable. 
Reliable  Systeas  (STARS)  Planning  and  Optimization 
Algorithms  foundation  Areas.  The  purpose  of  STARS 
was  to  create  well  designed  and  docusented  Ada 
software  for  rouse  by  agencies  within  the  Departeent 
of  Defense  (Dodi  as  well  as  defense  contractors. 

RAMORA.  a  Coeputer  Software  Configuration  lies 
tCSCl).  I*  based  on  an  object-oriented  design 
eephaslslng  reusability  and  portability.  At  the 
beginning  of  software  developseni.  a  reusable 
component  search  was  performed  on  several  governsent 
and  non-government  repositories  to  locate  candidate 
software  for  reuse.  Under  the  contract,  three  major 
reusable  Coeputer  Software  Components  (CSCs)  were 
created  within  the  RAMORA  software  .  Effectiveness, 
Criteria,  and  Optimization  (see  ngure  l).  This 
paper  presents  an  overview  of  the  RAMORA  software 
cosponents  followed  by  a  detailed  description  of  the 
Effectiveness  CSC.  Criteria  esc,  and  the 
Optimization  CSC. 


figure  1  RAMORA  Reusable  CSCs 


Rtunw.t  .(Magenta 

RAM5RA  is  a  decision  aid  which  automate*  the 
currently  manual  technique  of  deterslnlng  the  most 
appropriate  weapon  systeas  for  pairing  against 
designated  targets  a  menu-driven  interface  a  1  !■’*.* 
for  easy  manipulation  of  input  and  constraint  data. 
The  following  processes  are  facilitated  in  the 
RAMORA  software 

•  Development  of  a  target  list 

•  Development  of  a  weapon  systems  list 

•  Determination  of  the  weighting  factor 
priorities 

•  Manual  Inclusion  or  exclusion  of 
weapon/ target  pairs 

•  Oplialsatlon  of  target/weapon  pairings 

•  Displaying  tho  optical  solution 

mcauaju 

The  user  designates  target*  for  weapon  allocation  by 
selecting  froa  a  generic-type  target  data  base.  A 
list  of  designated  targets  is  developed  In  order  to 
allocate  the  available  weapon  systeas.  Options  for 
developing  tho  current  target  list  are  add.  delete, 
modify,  and  display  (generic  or  current)  targets, 
for  each  target  in  the  current  target  list,  thi 
priority,  probability  of  daeage,  hill  type, 
dimensions,  and  latltude/longltudo  position  arc 
entered. 

Woacnn  1,1st 

RAMORA  tracks  both  an  available  and  selected  weapor 
data  base.  The  user  selects  weapons  froa  the 
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available  list  10  bo  considered  for  assignment  u 
detlgnntcd  targets  RAMCRA  allow*  for  devclepMnt 
of  a  current  weapon  system*  ll*l  and  associated 
data  Option#  for  developing  the  »e»poo  Urn  ore 
*44.  dolet*.  modify.  and  display  (available  and 
current)  weapon  system*.  for  each  weapon  system  In 
ih«  selected  weapon  lUi.  iho  platform.  munition, 
forced  deployment.  platform  range  *nd  speed.  rest 
factor,  *e»rcliy  factor.  release  condition*, 
delivery  accuracies.  statu*.  end  latltudeTlongltode 
position  *re  entered. 

Weightier  rector* 

Verity*  feciors  ere  weighted  Into  the  weapon; target 
pairing  calculation*  such  a*  attrition,  cost, 
damage.  and  scarcity  of  the  weapon  systea*.  RamGRA 
Include*  an  Interface  to  allow  the  u*er  to  *et  the 
weighting  factor*. 

Kar.-al  ralriK 

RAMCRA  allow*  the  user  to  constrain  weepon.'target 
pair*  through  annua!  exclusion#  and  lnclu*len*  of 
we»ponf target  pair*.  An  exaaple  of  aar.ucl  inelu«lon 
Is  when  a  weapon*  officer  ha*  order*  to  pair  a 
particular  weapon  *y*te»  against  a  designated  target 
or  set  of  target*  when  solving  for  the  solution, 
the  optimisation  algorltha  will  aaVe  the  forced 
pairing  despite  the  cost  or  other  contradletlvn 
factor*. 

RaiUlmlaa 

•nsce  the  target  and  weapon  list,  weighting  factor*, 
and  possible  annual  Incluslons/escluslon*  are 
entered,  a  Mature  of  Mrit  aatrlx  I*  coaputed  that 
represent*  the  ‘cost*  or  criteria  of  allocating  each 
weapon  systea  to  each  designated  target.  The 
criteria  calculations  are  based  on  weaponjtarget 
effectiveness.  platform  survivability.  weapon 
scarcity,  weapon  cost,  tlae  on  target,  and  the  user- 
specified  weighting  factors,  weapon  effectiveness 
estimate*  are  defined  In  teras  of  single  sortie 
probability  of  damage  (SSPdt  and  the  number  of 
sorties  necessary  to  damage  a  target  to  a  prescribed 
level  INAascri  for  each  weapon  type.  The 
optlaixatlon  algorltha,  using  Integer  programming 
techniques,  then  assigns  weapons  to  targets  by 
alnlalxlng  the  sum  of  the  associated  criteria 
values  The  assignment  la  constrained  by  the 
available  nuaber  of  weapon*  of  each  type  and  the 
requIreMnis  for  damage  (HftQKT  values), 

Bi,iBl*y..,af  .ncsulu 

After  the  optlaixatlon  process,  the  solution  Mtrix 
can  be  displayed  for  review  and  aodlficatlons.  The 
optiaal  pairing  of  available  weapons  to  targets  Is 
displayed  In  an  easy-to-read,  color-coded  aatrlx. 
Multiple  solution  matrices  with  corrcspcnding 
weapon/target  lists  can  be  saved  and  then  restored 
for  review. 

Effcsilycncsa  CSC 

The  effectiveness  CSC  is  a  reusable  coaponent 
respotr  '•'*  for  aanlpulating  the  weapon 
effects  ;ss  estlaates.  The  Joint  Munitions 


effectiveness  Manual  tJkJM)  methodology  was  used  to 
calculate  each  weapon  effectiveness  cstiaato, 
single-sortie  probability  of  daaage  (SSPdj.  which  Is 
used  to  compute  a  cumulative  damage  probability,  and 
the  nuaber  of  sorties  required  to  damage  a  target  to 
a  specified  level  «I<M*ti.  The  4 MEM  methodologies 
were  developed  and  are  maintained  by  the  Joint 
Technical  Coordinating  Croup  for  Munition* 
effectiveness  UTtC/wgl  under  the  Joint  Chiefs  of 
Staff  to  model  mathematically  various  weapon  system* 
and  subsystems  for  weapon  effectiveness  estimate 
computations  Two  JW3<  methodologies  are 

incorporated  within  the  RAMORA  software. 
Alr-to-Surface  (Jwem/aSi  and  Surface-  to-Surfaeo 
tJM£M.3S).  Including  an  adaptation  to  the  JwtM/AS 
methodology  implementing  helicopter  deliveries 

Alr-i*.-Siirf»ss 

The  JwEMJAS  methodologies  are  open-end  methods  based 
on  Gaussian  delivery  error  and  ballistic  error 
distributions  for  a  rectangular  target  are*  element, 
assuming  the  target  elements  are  uniformly 
distributed  throughout  the  target  area  The  damage 
functions  are  limited  to  representations  that  are 
integrable  in  closed  form  with  respect  to  the 
Csusslan  delivery  error  and  ballistic  error 
distributions.  The  Jwem/aS  Mthodology 

considerations  begin  at  munition  release  from  the 
fixed  wing  airborne  plat.'  >.  therefore,  flight 
profiles  are  not  a  dependent  factor  in  the  weapon 
effectiveness  estimates 

The  JMCM/AS  Sasic  Manual  describes  the  derivation  of 
the  logio  and  mathematical  expression*  for  the 
methodologies  The  methodologies  are  modeled  by 
five  computer  methods  ; 

•  Ungulded  Weapon  against  hon- runway.  Unitary 
or  Area  type  Targets 

•  Culded  Weapon  against  Kon-runwsy.  Unitary 
or  Are*  type  Target* 

•  Project! le/Rocket  against  Non-run**y. 
Unitary  or  Area  type  Target* 

•  Ungulded  Weapon  against  Runway  type  Targets 

•  Culded  Weapon  against  Runway  type  Targets. 

In  addition  to  the  five  ccmputer  Mthod*  Is  the 
trajectory  Mthodology  that  recomputes  *  more 
accurate  and  representative  value  for  som  of  iho 
release  conditions  than  what  is  available  in  the 
tables  for  various  effectiveness  estimate 
compulations. 

The  JMEV/AS  computer  Mthod*  use  data  from  ten  files 
impleMnted  by  the  Automated  Weaponeering 
Optimisation  Program  (AWOP/JMEM).  The  files  are 
divided  into  the  following  dependencies  : 

•  Weapon  systea  dependency  files  -  platform, 
munition,  characteristics;  platform  and 
munition  pairings;  delivery  accuracies  end 
errors;  and  release  conditions. 

•  Target  dependency  files  -  target  charac¬ 
teristics  and  interdicted  aircraft. 

•  Weapon/target  dependency  files  -  effective¬ 
ness  indices  end  hard-target  reliabilities. 
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totlaamc  s^rfac* 

Th*  dMCM/Ml  methodology  implemented  in  the  Ramoaa 
software  orlgStotes  fro*  a  manual  for  evaluating  thn 
affae ilv«i*se  u"  nenr,velc*r  Indirect-fire  wcapsns 
ST*  inti  »r*»  targets.  Tto  methodology  is 
Independent  of  any  delivery  aspects  of  .he  land 
platform  when  the  weapon  effectiveness  estimates  are 
computed.  the  JMgx/SS  methodology  it  capable  of 
calculating  weapon  effectiveness  estimate*  for 
High-Explosive  (HCi  ar'  mpreved  Conventional 
Munition  OCX)  type  weapo 

A  data  foraat  wet  develop!  r  ihe  Kamoha  software 
bated  on  AKT /i*tM  data  :»ies  Fiv*  filet  were 
developed  and  are  represented  in  the  following  two 
groups  i 

•  Weapon  system  dependency  filet  -  platform 
and  munition  characteristics.  platfor*  and 
munition  pairings.  and  erro'  probabilities 

•  w*apon/iarget  dependency  file  -  lethal 
a  reat . 

the  target  data  wen  shtalned  </«*  the  target  file  In 
the  AWOf  data  bat*;  therefore  no  additional  target 
filet  were  needed. 

Uglkaaur  AsUemla 

while  a  tpeeiflc  Jwfix  methodology  doet  not  etitt  for 
helicopter  delivery  for  air-to-turface  munition*, 
the  JPOVAS  methodology  can  be  implemented  to 
compute  weapon  effectiveness  estimates,  Because  the 
munitiont  typet.  release  condition  parameter!,  and 
delivery  accuracies  for  helicopter  platforms  are 
similar  to  that  of  fixed  wing  aircraft,  the 
Cnguided,  Culded.  and  Frojecille/Roehet  JMEtt/AS 
methodologies  are  used. 

In  calculating  the  weapon  effectiveneta  ettimatet 
fer  weapon  tyttemt  with  helicopter  platformt.  the 
Awoh/Jwcw  file  format  used  for  the  jmem/as 
calculations  can  be  used.  In  addition  to  tne  ten 
awop/JMEM  filet,  one  file  was  developed  to 
Incorporate  present  and  possible  future  parameters 
In  delivering  weapons  from  a  helicopter  platform. 


CrUcrli  CSC 

The  Criteria  CSC  It  a  reusable  coaponent  responsible 
for  manipulating  the  criteria  values  for  the 
weapon/target  pairs.  The  optimization  algorithms 
evaluate  the  criteria  values  for  pairing  available 
weapon  systems  to  designated  targets.  The  criteria 
value  calculations  are  sensitive  to  the  baseline 
values.  including  the  user-related  weighting 
factors,  and  the  priority  ratio. 

b»»1Im  Salim 

The  baseline  values  are  factors  relating  to  the 
characteristics  of  avallaole  weapon  systeas  and 
targets.  ilAMOftA  uses  baseline  values  sensitive  to 
the  effectiveness  of  the  weepon  system  against  thn 
target,  expected  platform  attrition  rate  to  the 
target,  scarcity  of  the  weapon  system,  the  unit  cost 


of  the  wps pen  system,  and  the  time  for  the  weapon 
system  to  reach  the  target.  These  baseline  values 
are  normalised,  multiplied  by  the  weighting  factors, 
and,  where  appropriate,  multiplied  by  the  number  of 
weapons  required.  sssuT.  crer  operational  reasons, 
only  one  weapon  typo  is  paired  to  a  given  target  at 
a  specified  U»a.i  Each  of  these  preliminary 
criteria  values  for  each  weapon/target  pair  is 
normalised  by  the  maximum  criteria  value  for  all 
weapon/target  pairs  and  then  summed  with  the 
target’s  priority, 

rnsriiy  mua 

The  priority  ratio  ia  a  measure  Of  the  importance  of 
priority  when  determining  a  solution  to  the 
weapon/target  pairing  problem.  The  priority  ratio 
it  used  when  resources  arc  Insufficient  to  meet  the 
damage  requirements  of  all  the  targets,  and 
represents  the  criteria  value  assigned  to  a  target 
when  no  weapon  is  allocated.  The  weapon/target 
pairing  solutions  will  differ  depending  on  whether 
the  user  desires  to  maximise  the  number  of  targets 
destroyed  or  to  destroy  higher  priority  targets  at 
the  expense  of  destroying  mnre.  lower  priority 
targets.  The  priority  ratio  represents  the  number 
of  next  lower  priority  targets  that  would  be 
equivalent  to  the  higher  priority  target. 


aaiUlmlcn.CSC 

The  Optimisation  CSC  is  a  reusable  component 
responsible  for  optimising  available  weapon  systems 
against  designated  targets.  Optimization  !«  based 
on  the  weapon/target  effectiveness  estimates, 
weapon/target  criteria  values,  the  target's 
priority,  and  the  priority  ratio.  Two  algorithms 
are  implemented  in  RAMOKA.  Branch  and  Bound  Search 
Technique  and  the  Transportation  Cases  Method. 

grtnch  *ad  Bound 

The  branch  and  bound  search  technique  Is  similar  to 
an  enumeration  procedure  (computing  all 
possibilities),  except  that  usually  most  of  the 
non-optlmal  possibilities  are  discarded  without 
being  tested.  The  discarding  occurs  when  en  initial 
partial  assignment  Is  already  too  poor  a  selection 
to  becoso  optimal  regardless  of  which  remaining 
assignments  are  made. 

The  branch  and  bound  search  algorithm  consists  of 
two  primary  components,  branching  and  bounding.  The 
branching  end  bounding  is  similar  to  a  search  of  a 
tree  structure.  The  algorithm  branches  on  the 
assignment  of  one  of  the  remaining  weapons  and  then 
bounds  the  best  answer  that  could  be  expected  after 
this  assignment  is  made.  This  is  an  efficient 
solution  to  the  weapon/target  pairing  problem  due  to 
the  constraint  of  allocating  only  one  weapon  type  to 
each  designated  target. 

Transportation  Cason  Wethed 

Another  approach  to  solving  the  weapon/target 
pairing  problem  relies  on  the  traditional 
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■transportation*  problem.  Each  target  ha*  an 
associated  demand  for  weapons.  and  weapon*  have  an 
associated  supply.  Tito  problem  is  to  assign  the 
weapons  to  the  targets  In  a  manner  that  satisfies 
the  demand  with  the  available  supply  while 
minimising  the  sua  of  the  associated  criteria 
values.  The  problem  with  this  model  of  the 
weapon/urget  pairing  requirements  Is  that  the 
demand  Is  actually  a  function  of  the  weapon  type  and 
Is  a  matrix  of  values,  not  one  value  per  targai. 

A  modification  of  the  traditional  transportation 
approach  was  developed  by  solving  a  series  of 
transportation  problems  with  eaeh  case  consisting  of 
groups  of  weapons  and  targets  that  can  all  be  hit  by 
the  weapons.  This  method  works  well  when  most  of 
the  weapon  classes  consist  of  enough  weapons  to 
destroy  all  or  most  of  the  targets,  or  when  each 
weapon  class  contains  only  enough  weapons  to  destroy 
one  or  two  targets  at  a  time,  For  other  cases,  the 
computer  run  time  may  become  prohibitively  largo  for 
even  relatively  small  <10  weapons,  10  targets) 
problems.  A  result  of  this  algorithm  is  software 
for  the  generic  transportation  problem. 

Coablnatlnn  of  Algorithm* 

A  complex  scheme  was  implemented  for  the  HAMORA 
software  that  Incorporates  both  the  multiple 
transportation  cases  method  approach  and  the  brench 
and  bound  approach.  Each  of  these  approaches  works 
best  where  the  other  fAlls.  Before  optimising,  Die 
NROMT  values,  criteria  values,  and  controlling 
parameters  tslse  of  problem,  priority  ratio,  etc.) 
are  evaluated  to  determine  the  number  of 
transportation  cases  to  be  solved  If  that  approach 
were  taken,  if  the  number  of  cases  is  less  than 
some  predetermined  threshold.  KAMO HA  uses  the 
transportation  approach  to  optimise;  if  nut,  RAMORA 
uses  the  branch  And  bound  technique.  In  this 
manner,  the  true  mathematical  optimum  is  achieved  In 
a  timely  way  (see  figure  3), 


CancJLuMsn 

KAMO HA  is  a  decision  aid  automating  manual 
techniques  for  optimising  allocated  resources 
against  designated  requirements,  kamora  is  based  on 
using  an  object-oriented  design  emphasising 
reusability  and  portability.  Using  object-oriented 
design,  three  reusable  Computer  Software  Components 
were  developed  ;  effectiveness.  Criteria,  and 
Optimisation. 
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A  recurring  predicament  encountered  in 
developing  real-tia*  mabadded  Ada  aoftware  ia 
the  inflexibility  of  oompilar  Ad*  Run-Tiae 
Support  Enviroraenta  (ARTSE)  to  aeet  apecifio 
application  raqulreaenta.  That  la,  ocapilera 
lack  support  for  tailoring  and  extending  the 
ARTSE.  The  aeeond  short-casing  of  caapller 
ARTSE'*  ia  their  lack  of  extendlbility  dictated 
by  their  dedication  to  run-tiae  support  for 
only  Ada  language  conatructa  and  aeaantlca.  In 
reaponae  to  the  need  for  a  tallorable, 
extendable  run-tiae  aupport  environaent  for  Ada 
eabedded  application*,  Aerojet  EleotroSyateaa 
Corporation  (AESC),  Intermatrics,  Ino.  and 
Sparta  Ino.  have  teaaed  to  develop  the 
GENerallzed  Eabedded  State*  Specification 
(GENESYS)  tool  under  the  STARS  Foundation 
prograa. 

caicimAL  background 

A  principle  objective  of  the  Ada  language  ia  to 
offer  a  high  order  aedlui  for  the  dovelopaent  of 
reliable,  portable  aoftware  targeted  to  Eabedded 
Coaputer  Syateaa  (ECS).  A  n later  of  feature*  aro 
presided  within  the  aeaantlca  of  the  Ada  language 
to  addreaa  this  objective  that  traditionally  have 
been  considered  the  doaain  of  Operating  Systeas 
(OS).  Ada  lanpuge  primitives  offer  featurea  such 
as  aulti-tasklng,  synchronisation,  tine-based 
delays,  interrupt  handling  and  others  without 
forcing  the  applications  prog'aaaer  to  go  outside 
of  Ada  language  constructs.  To  achieve  this,  the 
Ada  oompiler  vendor  aust  provide  the  necessary 
control  wer  the  underlying  machine  to  support  the 
full  somantlo  richness  and  functionality  embodied 
within  the  Ada  language.  This  support  (ARTSE)  is 
provided  via  a  combination  of  compiler-generated 
code  and  a  collection  of  external  routines  that  nap 
the  abstractions  of  Ada  onto  the  bare  machine 
(typioal  of  ECS's)  or  onto  underlying  real-tine 
OS's.  The  ARTSE  is  not  directly  callable  by  the 
applications  programmer.  Rather,  the  applications 
code  is  resolved  to  ARTSE  interfaces  by  the  Ada 
Compilation  System  (ACS)  according  to  the  specific 
Ada  language  constructs  employed  by  the 
applications  programmer.  For  example,  an  Ada 


application  using  tasking  will  have  included  into 
its  executable  load  image  the  ARTSE  code  and 
routines  necessary  to  aupport  the  aulti-tasklng 
paradigm  on  the  hardware  to  which  the  ACS  is 
targeted.  The  intent  of  auch  a  scheme  la,  in  part, 
to  anhanct  the  portability  of  the  applloationa  code 
by  providing  the  applications  programmer  a  mtana  to 
aooeaa  powerful  features  without  directly 
interfacing  to  the  machine  or  OS.  A  major  weakneaa 
of  thla  approach  however  is  the  inability  of  the 
applications  developer  to  modify  or  "tailor"  the 
critical  components  that  may  lmpaot  the  run-time 
behavior  of  their  application.  An  ECS  often 
requires  high  degress  of  efficiency  that  may  not  be 
attainable  with  the  standard  ARTSE  components  and 
algorithms.  Obviously,  no  Ada  oospller  vendor  can 
anticipate  in  advanoe  all  of  the  unique 
requirements  of  a  given  embedded  system.  Hardware 
configurations  vary  widely  even  where  the 
instruction  set  archlteoture  remains  constant. 
Specialized  I/O,  mass  storage,  memory  management, 
and  oo-prooesslng  schemes  often  characterize  an 
embedded  system  archlteoture.  For  this  reason, 
run-tlmo  source  code  that  comprises  the  ARTSE  is 
supplied  with  many  vendors'  embedded  target  ACS's 
for  an  additional  licensing  fee.  Thla  permits  the 
modification  and  recompilation  of  the  ARTSE.  Using 
this  approaoh,  an  application  developer  can 
incorporate  specific  drivers,  interrupt  handlers, 
and  other  critical  run-time  algorithms  into  the 
embedded  systems'  support  software  in  place  of 
generalized  vendor  supplied  versions.  In  examining 
the  approaches  undertaken  by  various  developient 
projects  and  research  efforts  to  tailor  Ada  run 
time  behavior,  we  discovered  two  distinct 
strategies.  In  the  first  case,  the  source  code  of 
an  ARTSE  is  directly  modified  without  violating  the 
semantic  integrity  of  the  Ada  language  that  it  is 
supporting.  The  second  approach  is  to  bypass  the 
predefined  capabilities  of  Ada  that  are  deemed 
unsuitable  via  the  use  of  applications  level 
interfaces  and  services  (user-supplied).  Clearly 
any  solution  addressing  the  problem  of  run  tine 
tailoring  and  extension  must  support  both 
approaches  to  achieve  wide  application  and  utility. 

GEHESYS  provides  a  framework  methodology  and 
supporting  tool  to  facilitate  both  the 
oustoaization  and  reuse  prooesses.  GENESYS 
provides  an  automated  and  orderly  way  in  which  a 
user  can  easily  manage  and  exploit  tailorable  and 
reusable  components.  GENESYS  will  not 
automatically  alter  an  ARTSE  component  but  it  will 
strictly  control  and  manage  a  set  of  altered 
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components  -  both  ARTSE  and  applications  Icel¬ 
and  automatically  tailor  th«  construction  o f  the 
coaplete  executable  prograa,  GENESIS  accoaipllahea 
this  hr  assisting  the  uaer  In  the  characterization 
of  the  syata  to  be  constructed  and  then  by  drawing 
upon  an  existing  sat  of  available  tailored  ARISE 
alternative  components  In  atrlct  accordance  with 
the  user’s  specified  requlrimenta.  GENESIS  also 
provides  a  tool  framework  and  supporting 
aethodology  far  the  growth  and  aalntenance  of  a 
dynaalc  set  of  tailored  and  tailorable  coaponents. 
These  coaponents  c*ri  be  loth  ARTSE  and/or  non-ARTSE 
(e.g.  applications  level).  Jn  this  sense,  GENESIS 
can  be  characterised  as  a  productivity  enhanceaent 
tool  and  aethodology  that  facilitates  both  prograa 
construction  and  fineral  software  reuse  at  both  the 
ARTSE  and  the  application  layer. 

GENESIS  aaploys  a  set  of  abstractions  that  build 
upon  and  coapleaent  the  standard  architectural 
features  of  Ada  to  prwlde  wore  powerful  support 
for  the  construction  and  utilization  of  reusable 
software  building  blooks.  Key  to  this  strategy  is 
the  notion  of  discrete  CLASSES  of  services, 
alternative  lapleaentations  of  these  services  or 
INSTANCES,  the  coaplete  INHERITANCE  tree  of 
discrete  coaponents  which  aoaprise  any  given 
Instance,  and  the  set  of  quantifiable  ATTRIBUTES 
whloh  descriWi  nnd  characterise  the  behavior  of  any 
given  INSTANCE  of  a  CLASS. 

Borrowing  froa  object  oriented  prograaalng 
techniques  [3TB0M],  GENESIS  Introduces  the  notion 


cf  a  CLASS  to  build  upon  the  Ada  specification 
construct.  In  GENESIS  a  CLASS  apeciflea  a  related 
set  of  visible  exportable  services  (operations) 
and/or  structures  which  are  represented  at  the 
hipest  level  by  a  single  Ada  packs*  or  subprograa 
specification.  The  lowest  level  Class  is  a  single 
Ada  specification  iaplaaented  by  one  or  aore  body 
variations.  Higher  level  olaasea  can  be 
constructed  which  are  aggregates  of  other  Classes 
of  lower  level  services  and  structures.  Supporting 
and  iapleaentlng  this  set  cf  high  level  services 
are  any  nuaber  of  underlying  Ada  bodlea, 
specif ications  for  "withed"  units  (CLASSES 
theaaelves)  and  their  associated  bodies.  Within  a 
a  ASS  there  can  exist  any  mailer  of  variant  bodtea 
and  subolasaes  (withed  subprograa  units)  that 
laplenent  the  given  clasa  (Ada  specification). 
Thus,  a  GENESIS  CLASS  is  the  set  cf  callable  or 
visible  operations  and  structures  contained  within 
an  Ada  specification  aa  wall  aa  the  entire 
"Inheritance"  tree  of  all  poaalblt  Adi  subprogram 
bodlaa  and  supporting  subclasses  that  laplaient  the 
top  level  or  "root"  cists.  Since  CLASSES  can  be 
constructed  ee  eggregites  of  any  mabar  of  lower 
level  CLASSES,  very  oaeplex  tree-llke  structures 
can  result  that  depict  the  potential  component 
inheritance  structure  of  the  CLASS.  Any  Ada 
library  specification  oan  serve  aa  the  root  of  a 
olaaa  and  newer  aore  abstract  CLASSES  can  always  be 
built  on  top  of  ooabinationa  of  lower  level 
CLASSES.  GENESIS  aanagsa  the  context  necessary  to 
support  the  building  of  these  aore  .abstract  objects 
on  top  of  ooabinationa  of  lower  level  objects 


FIGURE  1.  CHESTS  BRINGS  a  ASSES  A  INSTANCES  TO  Ada 
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•Muring  that  th«  inheritance  structure  (th«  Ada 
dependency  tr««)  and  aaaociatad  b«haviora  arc 
aaintainad.  In  doing  ao,  GENESIS  promotes  good 
object  orl«nt«d  programming  praotica  by 
facilitating  th«  rauaa  of  well  deslfied  aASSES  for 
incluaion  in  other  yet-to-ba-d«veloped  hifiar  level 
aASSES. 

Conatructlon  c C  a  semantically  correct  executable 
program  obvloualy  requirea  the  aelection  of  a 
•ingle  Ada  body  for  each  apeelfication.  An 
INSTANCE  ia  the  path  within  the  tree  where  cholcea 
have  been  Made  at  each  point  that  a  body 
alternative  (and  ita  Inheritance  of  wlthed  unlta) 
ia  available.  Figure  \  repreaenta  a  high  level 
a  ASS  of  acrvloea  —  On  Board  Heaaaga  Faaaing— 
with  two  very  diatlnct  implementation!.  Inatance 
MESS  AG  ES_0  V  ERJtS2 3 2_A  ia  comprised  of  thoae  lower 
level  unlta~whlch  implmaant  the  message  passing 
aervicea  for  a  hardware  target  which  coamunioatea 
over  an  RS-232  bua  while  inatance 
MESSAGES_OVE*ETHEKNETJB  implements  the  same  act  of 
hitfi  level  Miug)  aervicea  for  an  ethemet  based 
architecture.  The  notion  of  an  INSTANCE  definition 
and  ita  aaaoolated  Inheritance  atructure  of 
components  inaulatea  the  user  (a  programmer)  of 
auch  a  aervloe  fro*  the  detaila  of  ita 
lapleaentatlon.  It  alao  provides  a  convenient 
aethod  of  managing  differing  veraiona  or  releaaea 
of  aoftware  aervicea.  The  user  di scrlftinatea 
between  instances  based  upon  behavioral  and  other 
relevant  attributes  defined  for  a  given  aASS  and 
the  variable  eapirical  values  assigned  to  those 
attributes  Tor  each  separate  INSTANCE  that  has  been 
defined.  The  attribute  characterises  the  aASS 
while  the  attribute  values  characterise  each 


INSTANCE  of  that  aASS.  Referring  to  Figurn  1 
aga'n  we  see  that  the  two  instances  of  the  Message 
Fassing  service  vary  widely  with  respect  to  both 
speed  and  memory  utilization  thereby  allowing  a 
user  to  discriminate  between  the*  and  make  a 
aelection  baaed  upon  these  two  important  behavioral 
attributes  (assisting  the  cosmunlcetion  hardware  has 
not  yet  been  selected). 

Key  to  the  GENESIS  concept  ia  the  notion  of  a 
SESSION.  The  GENESIS  SESSION  contains  all  of  the 
aASS  INSTANCE  selections  that  a  user  has  made  in 
order  to  support  the  construction  of  a  compiled 
and/or  executable  (linked)  ayatea.  Once  created, 
the  SESSIONS  are  aim  fid  by  GENESIS  and  can  be 
saved,  recalled,  copied,  modified,  or  deleted  fron 
the  ayoten. 

The  following  sections  discuss  ths  installation  of 
classes  and  inatancea,  how  a  programmer  would  use 
GENESIS  to  select  class  instances  and  build  a 
session,  and  how  GENESIS  fits  into  the  software 
life  cycle. 

TIN  LUNARIAN'S  MLR: 

CREATING  A  MAINTAINING  aASSES  AND  INST  AN  CIS 

In  order  to  use  GENESIS  as  a  tool  to  aaaiat  in 
tailoring  and  reusing  Ada  ooaponents,  it  is 
necessary  to  first  place  thoa*.  coaponents,  and  a 
variety  of  information  about  them,  in  the  GENESIS 
database.  This  is  the  librarian's  role  —  to 
oollect  caajonenta  and  place  the*  in  an  organized 
fashion  into  a  library  where  users  will  later  be 
able  to  find  them  easily. 
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Change  the  Library  Password 
Create  a  New  Class 
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FIGURE  2.  THE  C BESTS  INTERFACE  IS  BAST  TO  UNDERSTAND 
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GENESIS  provide*  a  staple,  aanu-driven  user 
interface  to  aaaiat  In  the  librarian'*  duties.  Tb*i 
uaar  Interface  la  baaed  on  the  X  windowing  ayatea, 
a  standard  paekapi  of  routines  for  manipulating 
windows,  Icons,  aouse  and  pointer  (WIMP).  Figure  2 
Illustrates  the  opening  screen  of  GBtESYS.  In  the 
upper  left  of  the  window  is  a  "selectable  list"  of 
coaaanda  that  can  be  Invoked  frea  this  window. 
Clicking  the  aouae  while  the  oursor  is  on  one  of 
these  coaaanda  will  cause  the  ooaaand  to  be 
invoked.  If  the  first  ccaaand  in  the  list  (BROWSE) 
is  selected,  two  new  eleaer.ts  appear  on  the  screen: 
a  sassage  box  (in  the  lower  right)  and  a  new 
selectable  list  (in  the  lower  left)  (see  figure  3). 
The  aeasage  box  instructs  the  user  to  sake  a 
selection  in  one  of  the  lists,  and  to  press  the 
"CONFIRM"  button  to  cause  the  seleotlon  to  take 
effect.  This  sequence  is  typical  of  the  dialog 
between  the  user  and  GENESIS  for  all  ooaaand 
functions.  The  use  of  the  confiraation  via  the 
aessagi  box,  plus  the  general  avoidance  of  coaaanda 
that  require  the  user  to  type  a  response  ia 
designed  to  alnlalxe  user  input  errors  or 
aablgulties  concerning  acceptable  Inputs. 

For  the  librarian,  there  are  four  basic  operations 
that  need  to  be  performed  in  GENESYS: 

o  Adding  new  ooaponents  (Ada  specifications  and 
bodies)  to  the  database, 

o  Creating  new  instances  froc  existing 
ooaponents, 

o  Deleting  instances,  and 


o  Deleting  Ada  coaponenta  froa  the 
database. 

Each  of  these  operations  is  aocoapanled  by  a  aeries 
of  dialogs  between  GENESYS  and  the  user  with 
GENESYS  restricting  the  actions  the  user  can  take 
to  ensure  that  inconsistent  or  erroneous 
installations  cannot  take  place. 

To  install  a  new  class  in  GENESYS,  the  user  selects 
"Create  a  New  Class"  fra  the  ooaaand  list  on  the 
sain  screen,  shown  in  figure  2,  and  then  fills  in 
the  necessary  information  in  response  to  queries 
froa  GENESYS.  In  particular,  the  user  auat 
provide: 

o  The  naae  of  the  new  class, 

o  The  location  of  the  source  code  file  for  the 
class'  Ada  specification, 

o  The  location  of  a  help  file  describing  the 
class, 

o  The  naaes  of  the  attributes  that  will  be  used 
to  distinguish  the  various  instances  cf  the 
class,  and  locations  of  attribute  help  files 
that  describe  the  Meaning  rf  the  attributes. 

Next,  the  user  aust  describe  the  relationships 
between  the  new  class  and  existing  ooaponents  in 
the  database.  One  siaple  rule  dictates  the  order 
of  installation  of  new  components:  Before  any  new 
specification  or  body  can  ba  added,  all  package 
specifications  that  are  "wlthed"  by  the  new 


Create  a  Hem  Session 
Delete  a  Class 
Delete  a  Session 
Edit  a  Class 
Edit  a  Session 
Eiit  GENESYS 


FIGURE  3.  GBI  IS  IS  WIENS  USERS  THROUGH  OPERATIONS 
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coaponant  auat  already  be  installed  in  the 
database.  In  other  words,  installation  proceeds 
fro#  the  bottCM-up.  Low-level  pack* *15  auat  be 
present  before  hi^ier-level  exponents  that  aro 
directly  dependent  on  the  lcwer  level  coaponenta 
can  be  added.  This  ia  necessary  to  avoid  any 
situation  where  an  Ada  specification  or  body  in  the 
database  will  not  coaplle  because  it  lacks 
supportlnc  units.  Likewise,  when  a  class  is  to  le 
reaoved  frca  the  database,  it  aust  be  at  the  top  of 
its  "dependency  tree"  —  it  cannot  be  reaoved  if  it 
ia  "wlthed"  by  any  other  ooaponent.  GENESIS 
assures  this  ooaponent  closure  property  at  all 
tlaes  Maintaining  a  consistent  database. 

The  final  step  in  the  dialog  for  adding  a  new  class 
ia  to  indicate  the  connections  to  lower  level 
ooaponents.  GENESIS  asks  whether  there  are  any 
"subclasses"  to  the  Installed  classes.  These 
"subclasses"  are  those  peokagn  specifications  that 
are  "wlthed"  by  the  class  being  installed.  The 
librarian  aust  enter  the  naaes  of  all  subclasses 
that  the  class  directly  "wltha. "  GENESIS  checks  to 
ensure  that  the  aubslassea  have  already  teen 
installed.  This  establishes  the  links  within  the 
database  that  will  be  used  when  coaponenta  are 
retrieved,  ensuring  that  all  supporting  coaponenta 
are  also  retrieved  for  coepllatlon  into  the  prop*aa 
library. 

After  a  collection  of  components  are  placed  in  the 
database,  it  ia  necessary  to  create  Instances  fro* 
the  olasaea  of  these  casponents.  To  define  an 
instance,  the  librarian  first  chooses  a  class  in 
the  database.  GENESIS  then  asks  for  soae  gtneral 
information  about  the  new  instance  to  be  doflned: 

o  The  naae  of  the  instance, 

o  Location  of  a  help  file  describing  the 
instance,  and 

o  The  values  of  the  attributes  for  the  instance. 

Recall  that  attributes  for  the  class  in  general 
were  defined  when  the  class  was  installed.  The 
attribute  values  are  in  the  fora  of  a  nuaeric  range 
(1..10).  These  values  are  used  to  assist  the  user 
in  selecting  a  specific  Instance  of  the  class  that 
best  fits  their  needs. 

The  librarian  next  proceeds  dewn  a  "dependency 
tree,"  and  aust  aake  a  selection  oC  a  single  body 
to  support  each  specification  encountered  in  the 
tree.  GENESIS  leads  the  user  through  the  tree  and 
lists  the  available  alternative  bodies  at  each 
branch  in  the  tree.  Vhen  this  selection  process  is 
ccaplete,  the  instance  definition  is  entered  into 
the  database  and  now  represents  c  complete, 
coherent  suite  of  caapilable  Ada  units  able  to 
provide  the  services  defined  by  the  class. 

For  deletion  of  ccaponents  from  the  database, 
certain  rules  aust  be  enforced  by  GENESIS  to 


protect  the  coherency  ct  the  database.  Sessions 
can  be  deleted  at  any  tiae.  Hcwevor,  an  Instance 
can  only  bn  deleted  if  it  is  not  Included  in  any 
existing  session.  Deleting  an  instance  currently 
in  use  would  leave  at  least  one  session  in  an 
inconsistent  state.  Removing  sessions  and 
instances  does  not  cause  the  rwoval  of  any  actual 
Ada  ooaponents  free  the  library.  To  delete  bodies 
and  specifications,  further  prerequisites  aust  be 
aet. 

To  delete  a  class,  it  is  necessary  to  reverse  the 
process  of  adding  coaponenta,  and  10  delete  frae 
the  "top  down."  Before  a  class  can  be  deleted,  any 
instances  rooted  in  the  class  aust  first  be 
deleted.  If  the  user  ia  able  to  delete  all  such 
Instances  safely,  the  class  itself  aay  be  deleted. 
Vhen  this  la  done  GENESIS  autaaatlcally  deletes  the 
olaaa  specification  and  any  set  of  available  bodies 
in  the  database  (since  they  are  aeanlnglesa  without 
the  specification). 

Individual  body  coaponenta  can  be  reaoved  at  any 
tlaa,  but  only  if  the  body  Is  aot  the  last  body 
present  in  the  database  to  support  it's  class 
specification.  If  there  are  Multiple  alternate 
bodies,  then  removals  are  penaitted.  However, 
reaovr.1  of  the  last  body  would  leave  the 
corresponding  specification  part  in  an  unusable, 
and  therefor#  erroneous  condition,  and  consequently 
la  not  remitted.  The  specification  and  tho  last 
body  aust  ba  reaoved  together. 

By  using  this  dialog  framework  for  the  librarian's 
baslo  chores  of  entering  and  deleting  body  and 
specification  ccaponents  and  defining  and  deleting 
instances,  the  consistency  and  coherency  of  the 
GQtESYS  component  library  can  be  safely  Maintained. 
Another  technique  to  assure  safe  database 
Modification  is  to  minimize  the  maber  of  accesses 
to  the  database.  A  group  of  related  additions  or 
deletions  is  held  by  GENESIS  until  a  casplete  set 
of  aodificatlons  is  acoinulatad.  Then  the  entire 
batch  of  changes  is  sent  via  SQL  to  the  database, 
thereby  decreasing  the  chances  of  an  interruption 
in  the  process  (by  syst«  failure  or  other  oeuses). 

BUILDING  APK.ICATI0N5  WITH  CHESTS 

In  the  grand  scheae  of  reuse  (figure  k),  GENESIS 
provides  library  management  end  application  build 
capabilities.  It  permits  a  user  to  pleco  togither 
an  application  by  concentrating  at  the  level  of 
abstraction  expressed  by  the  class  specifications 
he  or  she  wishes  to  incorporate  into  the  design. 
In  other  words,  GENESIS's  library  manageeont  scheme 
encourages  a  building  blook  approach  to  software 
development,  where  the  user  sees  only  the  jagged 
edge  of  the  block  to  which  his  application  is 
intended  to  connect  and  the  build  capabilities 
insulate  the  user  frca  the  actual  structure  during 
the  process  of  source  code  compilation.  Thus  the 
class  specification  literally  specifies  the  tip  of 
the  iceberg  to  which  the  user  wishes  to  attach 
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(rigure  5).  Since  auch  class  specifications 
represent  the  embodiment  of  the  reusable  portion  of 
an  objeet  and  no  aore,  GENESIS  strongly  eabraces 
the  software  engineering  principle  of  infnrsaticn 
hiding  and  encouragis  the  uae  of  abstract  data 
types  in  designing  classes. 

There  are  aix  distinot  steps  in  building  an 
application  through  a  GENESIS  session.  The 
following  paragraphs  detail  the  steps  and  provide 
an  ennple  of  a  GENESIS  session. 

Stop  1:  Identify  an  Application  and  Select  a 
Ccipooont  to  leuaa.  The  process  of  using  GEKESYS 
is  a  multi-step  process  that  first  involves  the 
selection  of  a  class  specification  to  use  in 
building  the  targit  application.  Vhile  GENESIS 
provides  a  capability  for  browsing  through  the 
oonponent  library,  it  is  United  in  aiding  the  user 
in  asking  this  selection  (i.e.  it  has  no  true 
doaaln  analysis  capability).  This  is  because 
GEKESYS  does  not  taxonoaically  olassify  its 
exponents  or  provide  a  user  tailorable  knowledge 
base  to  help  a  user  decide  which  classes  to  use. 
There  is  no  inherent  reason  why  such  capabilities 
could  not  be  added  to  the  tool,  and  indeed,  as 
future  funding  and  tine  peralt,  these  important 
capabilities  will  be  added. 

Step  2:  State  Oner  Constraints  and  Preferences. 

Initially,  the  restrictive  vision  of  class 


ooaposition  nay  aeea  aosewhat  unoonfortable 
(especially  given  the  iceberg  analogy).  To 
alleviate  thia,  GEKESYS  provides  the  notion  of 
class  attributes  which  can  be  umH  to  express  the 
concerns  or  constraints  of  the  user  reprding  the 
iceberg  he  or  she  has  just  selected.  Is  it  too 
large?  Is  it  fast  enough?  Is  it  hardware  specific 
or  ia  it  portable?  It  is  this  process  of 
constraining  the  choloe  that  beccnes  the  second 
step  in  the  process  of  using  GENESIS  to  build  an 
applioation. 

Step  3:  Select  an  InplanenUtlon.  The  next  step 
is  for  the  user  to  choose  an  iaplvaentation  of  that 
olass  that  best  fits  within  his  applioation 
constraints.  Attributes  peralt  the  developer  to 
perforn  this  second  step  without  resorting  to  a 
primitive  and  tine  consuaing  source  code  analysis. 
GENESIS,  using  a  scoring  technique  similar  to 
Internetrics'  Reusable  Software  Library  [B01T87], 
aakes  reccnnendations  based  upon  preferences  stated 
by  the  user  in  terns  or  attribute  values  or  permits 
the  aore  taowledgsable  user  to  select  an  instance 
by  directly  viewing  a  list  froa  the  library. 

Step  A:  Save  the  Selection (s).  Cnee  the  selection 
is  aade,  GENESIS  performs  the  fourth  step  which  is 
to  record  the  user's  selected  classes  and  instances 
into  a  group  known  as  a  session,  where  the  session 
represents  the  entire  collection  of  class/instance 
pairs  that  the  user  has  chosen  for  his  application. 
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The  session  is  versatile  in  that  tha  user  can 
crsata  ona  or  more  saaaiona  for  aach  application, 
thereby  keeping  a  stored  variety  of  la  plantations 
for  a  single  application  that  can  ba  callad  up  and 
built  without  having  to  rawrlta  application  coda. 
This  capability  paralts  a  uaar  to  craata  an 
application  and  taat  it  with  several  different 
versions  of  a  reusable  coaponent  in  order  to 
evaluate  tha  perforaance. 

Step  5:  Generate  a  Representation  of  tha 
Selections.  Having  a  session,  tha  uaar  can  than 
porfora  tha  fifth  step  of  creating  a  Vendor 
Intarfaoe  File  (VIF),  which  is  a  textual 
re  presents  tier,  cf  all  the  source  cods  nodules  known 
to  the  library  that  ara  needed  to  build  the 
application  according  to  the  user's  specifications. 
The  VIF  is  automatically  crested  by  GENESIS  by 
analyzing  the  session  class-instance  pairs  snd 
information  stored  about  the  instances  within  the 
GENESIS  database.  Thus,  in  this  fifth  step,  the 
user's  abstract  specification  is  turned  into  a 
script  by  which  a  compiler  can  build  the 
application.  In  the  initial  version  of  GENESIS,  we 
attempted  to  Incorporate  the  user's  code  direotly 
into  tha  VIF  but  soon  realized  that  the  process  of 
specifying  a  large  user  application  could  be  quite 
tedious.  For  this  reason,  the  current  tool  only 
addresses  the  source  code  nodules  needed  to 
construct  the  classes  selected  freer  the  GBJESIS 
database.  The  VIF  can  be  used,  however,  as  a 
ampliation  order  script  to  ocnplle  the  source  code 
into  the  users  working  Ada  library  or  as  an  Ada  Hun 
Tine  Support  Environnent  (AHTSE)  reconstruction 
sorlpt  for  a  Custom  Build  Tool  (C8T)  to  use  to 
alter  the  content  of  an  ARISE. 

Step  6:  Place  the  Seleoted  Components  Into  the 
Qaer's  Library.  This  step  in  building  an  AHTSE  or 
canpiling  code  into  a  local  library  is  the  sixth 
and  final  step  in  using  GENESIS  and  due  to  a 
special  tool  called  the  File  Transfer  Tool  (FTT) 


can  ba  perfornad  in  a  development  environment  where 
the  GENESIS  host  system  (a  Sun  workstation  running 
X)  and  tha  targat  amiroraent  are  aeparate  but 
connected  (by  a  network  or  RS-232  link). 

Let  ua  now  consider  an  example  ualng  GENESIS  to 
select  alternative  message  passing  algorithms. 

Step  1:  Identify  an  Application  (i.e.  Create  a 
Station)  and  Chooaa  a  Cmponent  to  Reuaa  (l.a. 
Select  a  Claaa).  Let  us  consider  a  cast  in  which 
wt  wish  to  anploy  a  simple  string  massage  passing 
scheme  in  an  application  that  will  raside  on 
distributed  hardware.  First,  tha  usar  creates  a 
session  which  will  hold  the  specification  for  all 
Of  the  components  that  will  be  used  fren  the 
GENESIS  library.  This  session  is  named 
Message_Test.  The  olass  that  is  selected  is  named 
Hessage~and  basically  provides  a  simple  scheaa  in 
which  each  task  has  a  single  queue  to  contain  its 
messages.  These  queues  can  be  addressed  by  using  a 
unique  TaskJCD  that  must  be  assigned  manually  (and 
caref ully^while  designing  the  application(s). 
Class  Message  is  represented  by  the  following 
specification: 

package  MESSAGE  ia 

HA XI HUM  MESSAGE  LENGTH  :  constant  POSITIVE  :* 

K_096;- 

subtype  HESSAGE  TIPE  is 

STRINGd.  .MAXIKJM_KESSAGE_LENCTH); 

type  TASK_ID_TIPE  is  new  INTEGER  range  1 .  .255; 

procedure  RECEIVE( 

RECEIVER  :  in  TASK  IDTIPE; 

SENDER  :  out  ?ASK_ID_TIPE; 

MESSAGE  :  out  HESSAGEJTIPE); 

procedure  SEND( 

DESTINATION  :  in  TASK_ID_TIPE; 
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SOURCE  :  in  TAS)(_XD_TYfE; 

MESSAGE  :  in  WSSWEjrm); 

•nd  MSS  ACC; 

Stop  2:  Stele  8 Mr  Ooutnlsti  ud  rrtftrMMi 
(l.a.  M  Attribute  Values).  Qui  Message  has 
thr««  simple  attributes,  nsnely  Spend,  Memory  and 
Mil  ability  where  a  hi#>  5  pod  value  reflects  a 
faat  message  passing  instance,  a  hi#)  Mnory  value 
reflects  the  usage  of  a  large  amount  of  aaaory  by 
tha  lnatanoa  and  a  hi#)  Reliability  valua  reflects 
an  lnatanoa  In  which  sassages  hava  a  high 
probability  of  arriving  »t  thalr  daatlnatlon 
eorraotly,  Tha  uaar  of  cur  hypothetical  olaaa 
expresses  tha  following  prafaranoaa  (on  a  acala  of 
1. . 10): 


Spaed 

■  9 

(Hi#)  Spaed) 

Memory 

«  5 

(Hodarata  Haaory 

Utilization) 

Xal lability 

*  2 

(Low  Reliability  Tolerated) 

Stop  3:  Sal  act  an  laplMaoUtloa  (l.a.  Ask  for  an 
Instance  Reooeanendatlott).  Assialng  that  olaaa 
Message  haa  aavaral  lnatanoaa  aa  shown  in  figura  6, 
GEXESYS  racoamtnda  tha  Faat_Buffarad_Maaaagaa 
lnatanoa  ovar  tha  raohetixed_Hessagea_Vith_Ratrlat 
and  Unbuffered_HeaaegM  lnatanoaa.  This  lnatanoa 
is  rac<Mand*d~by  tha  tool  bacauaa  of  Its  apaad  and 
■odarata  aaaory  utilization. 


Stop  R:  Sava  the  Salaotlea(a)  (l.a.  Sava  tha 
Sasaloa).  Tha  uaar  than  instructs  GEXESYS  to 
aoeapt  tha  racoeaandatlon  and  aava  it  in  tha 
aaaalon  Hassegajreat.  This  lnforaation  lJ  updatad 
both  In  a«aory7  vhare  tha  uMr  works,  and  In  tha 
database  froa  which  it  oan  ba  latar  retrieved.  At 
this  point  the  aaaalon  ltaelf  corraaponda  to  tha 
application  being  developed  and  contalna  the 
specification  of  a  class  (Haaaaga)  and  an 
iaplaaentation  of  that  class 
(Fait_Bufferad_HeaMgea)  needed  by  tha  application. 

Step  5>  Generate  a  Representation  of  tha 
Seleotlons  (l.a.  Spaolfy  tha  Source  Coda  by 
Generating  a  VXF).  At  this  point  tha  uaar  la  ready 
to  begin  tha  build  process  for  his  application.  To 
acocapllsh  this  a  VXF  la  generated  at  tha  request 
of  tha  user.  Tha  user  is  free  to  view  (or  even 
adit)  tha  VXF,  but  need  not  do  so.  This  file  la 
tha  prlaary  input  to  tha  Cuatcn  Build  Tool.  Xn  our 
case,  tha  VXF  will  contain  tha  rile  Identifiers  for 
Hassaga_Spae,  Message_Body_1 ,  Buffer_Hgr_Spec, 
Buf  f  ar_Ksr_Body_i”|  Fast_Bus_Hgr_Spao, 
Fast_Bus_b jr_Body_1 ,  Router_3peo  and  Router_Body_l 
In  compilation  order.  The"  fact  that  tha  uaar  is 
not  neoessarily  ewara  of  tha  contents  of  thla  file 
la  important  and  cannot  ba  emphasized  enough.  Tha 
uaar  need  only  ba  aware  of  tha  class  Hasaage  and 
tha  abatraot  notion  of  tha  Instance 
Faat_Buffarad_Hassages  which  la  fast  and  does  not 
utilTsa  a  great  deal  of  aaaory.  When  tha  VXF  is 
generated  from  information  contained  In  the 


FIGURE  6.  IBB  MESSAGE  CLASS. 
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library,  the  details  on  how  to  construct  the 
instance  are  autcmatically  filled  in  for  the  user. 

Stop  6:  Place  the  Selected  Caapooents  Into  the 
Deer's  Library  (i.e.  Invoke  the  CBT).  The  CBT  can 
either  provide  the  ability  to  rebuild  an  AST5E  and 
compile  user  classes  in  the  caso  of  a  cross 
compilation  system  tarpat  or  Just  compiler  user 
classes  for  a  host-heat  compilation  systta.  The 
GST  parses  the  VIP  and  psneratos  the  ACS  specific 
invocation  necessary  to  insure  the  compilation  into 
the  appropriate  Ada  library  of  all  code  specified 
in  the  VIP.  Tho  user  need  only  lnfora  the  CBT  of 
the  target  Ada  library.  Cnee  tho  COT  has  been 
executed,  the  user  can  ccapllo  his  application  code 
against  the  new  installed  claasea  or  link  his 
application  in  order  to  create  a  program  containing 
his  tallorod  ARTSE.  In  our  example,  running  the 
CBT  will  sin  ply  ccapile  all  of  the  apeciflcatlona 
and  bodlea  needed  to  iaplenont  the 
Fa3t_Buffcred_H03sacea  instsnee  Into  his  working 
library.  Cur  ssap-le  user  la  then  free  to  writo  the 
application  code  that  will  use  tho  elaaa  Heasage 
specification  and  compile  against  it.  When  tho 
application  code  is  done,  the  user  can  link  to 
obtain  a  load  nodule  containing  the 
FastJUffered^Hossagoa  inatanco. 

G BUSTS  AMD  THE  SOFTWARE  DEYKLOPKBfT  PROCESS 

As  was  seen  in  the  prior  seotions,  GENESIS  is,  in 
general,  a  reuse  support  tool  and,  specifically,  a 
tool  supporting  tho  tailoring,  as  well  as,  the 
reusing  of  ARTSE  and  application  ccmpononta.  To 
properly  utilise  GENESIS  in  a  software  application, 
the  development  teas  should  supplement  tho  normal 
software  llfo-eycle  process  as  early  as  the 
software  requirements  phase  in  of  recognition  the 
potential  impact  that  GENESIS  cay  have  on  analysia, 
design,  implementation,  testing  and  integration. 
Figure  7  presents  a  traditional  "Vatorfall"  diagram 


of  the  software  developaent  process  annotated  to 
show  the  effects  GENESIS  can  have  on  the 
developaont  process.  The  following  paragraphs 
discuss  the  changes  to  the  software  development 
process  required  to  take  full  advantage  cf  GENESIS. 

Figure  7  shows  that  during  the  software 
requirements  definition  phase,  GENESIS  should  be 
considered  within  two  contexts.  First,  when  tho 
requireaents  for  the  software  system  are  being 
defined,  tho  analyats  must  also  consider  the 
requireaents  of  tho  Ada  Run-Tine  Support 
Environaent  (ARTSE).  Isauoa  of  potential 
laportanoQ  include  Ada  Language  Reference  Kanual 
(LRU)  chapter  13  support  snd  algorlthaic 
performance  eharacterlatica  cf  the  ARTSE.  The 
ARTSE  requirement?  play  a  key  role  in  tne  selection 
cf  the  production  Ada  cempller  for  tho  systen. 

Second,  while  defining  the  requirements  for  the 
systea,  the  analysts  should  be  able  to  identify  tho 
availability  of  GENESIS  olasaoa  that  already  exist. 
With  tho  knowledge  of  thoso  existing  classes,  tho 
analysts  can  specify  the  requirements  in  a  manner 
that  will  not  later  precludo  their  reuse.  To 
prevent  restrictive  requirements  definition,  the 
analysts  should  follow  an  iterative  process  of 
identifying  the  requirements,  reviewing  available 
classos  and  specifying  the  requirements.  If  tho 
analyst  finds  one  or  aero  classes  that  aay  satisfy 
tho  requirements  of  tho  syatea,  the  requirements 
should  be  deflnod  such  that  use  of  any  cf  the 
olaasoa  is  not  prooludod.  Depending  on  tho 
perceived  olosoneas  of  fit,  the  requirements  can  bo 
defined  in  such  a  manner  as  to,  in  fact,  oncouraga 
tho  use  cf  available  classes. 

During  top  level  design  —  defirdtlon  of  seftwaro 
interfaces  —  the  designers  will  identify  the  new 
GENESIS  classos  required  for  tho  application.  As 
figure  7  depicts,  there  are  two  baric  types  of 
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FIGURE  7.  GENESIS  DEPICTS  ON  TUB  DEVELOPPBPT  PROCESS 
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classes :  ARISE  and  USER.  The  new  ARISE  eltiMt  to 
b*  defined  ara  for  thoa*  part  a  o f  the  selected  Ada 
compiler's  ARTSE  that  requirt  tailoring  and  for 
which  no  existing  ARTSE  classes  currently  exist. 
Tha  same  appllaa  for  USER  eltases  —  elaaaaa  that 
laplaaent  ayatem  level  or  appllaatlon  specific  but 
not  ARTSE  functionality.  Once  thaaa  USER  elaaaaa 
have  bean  defined,  their  interfaces  can  be 
apeclfled.  Xntarfacea  for  ARTSE  elaaaaa  are 
already  defined  by  the  Ada  compiler.  However,  the 
elaaaaa  of  run-time  support  which  require  tailoring 
must  I*  added  to  (installed  in)  GENESIS.  (A  common 
interface  standard  for  Ada  run-time  ay  at  mas  would 
eliminate  the  need  to  install  new  ARTSE  olaasea 
eaoh  time  a  different  oaapiler  la  used.)  ARTSE 
elaaaaa  can  initially  be  inatalled  with  only  their 
default  (vendor  supplied)  instances.  Tailored 
instances  can  be  added  later.  On  the  other  hand, 
USER  classes  can  be  new  and  therefore  require 
apaoifioation  of  the  interfaoe  as  well  as 
installation  of  the  class.  (Class  installation  ia 
discussed  above.) 

Onoe  development  advances  to  the  deaigi  phase,  the 
dealgiera  are  required  to  define  the  lnstanoea  of 
the  new  ARTSE  and  USER  classes.  This  process  ia 
generally  no  different  than  the  detailed  design  of 
other  software  components.  However,  thr 
development  team  should  keep  in  mind  that  since  the 
GEMESYS  USER  olaasea  tend  to  be  ayatem  level 
(executive)  or  utility  routines  used  by  many  other 
software  components,  the  interfaces  for  these 
olaasea  should  be  implemented  early  to  provide  the 
basia  for  designing  other  opponents.  A  final 
point  in  the  detailed  design  of  class  lnstanoea: 
multiple  lnatancea  for  a  class  may  be  initially 
defined.  The  reason  for  the  development  of 
multiple  instances  ia  to  provide  alternatives  with 
different  characteristics  that,  depending  on  the 
actual  final  system  and  environment,  nay  be 
optisue.  This  approach  reduces  the  project  and 
component  development  risk  since  it  is  likely  that 
one  of  the  developed  instances  will  meet  both 
component  and  overall  system  requirements.  An 
example  would  to  two  instances,  one  that  optimizes 
for  apeed  and  one  that  optimizes  for  memory 
utilization.  If  memory  is  constrained  in  the 
system  and  preliminary  analysis  shows  that  seme 
components  may  need  optimizing  for  memory,  it  say 
be  desirable  to  deaigi  both  instances.  The  pal 
would  be  to  use  the  speed  optimized  instance  unless 
memory  dictates  otherwise. 

Implementation  prooeeds  normally  with  one  small 
addition.  As  class  instances  become  available, 
they  need  to  be  added  to  GQIESIS  in  the  manner 
defined  above.  Once  inatalled  in  GENESIS,  they 
become  available  to  all  programmers  for  unit 
teating. 

Since  GENESIS  actually  performs  the  build  prooesa- 
-  compiling  the  source  code  for  the  session 
instances  into  the  user's  library  —  GENESIS 
directly  supports  the  integration  process.  GENESIS 
also  facilitates  the  testing  of  alternative 
implementations  to  assess  their  impacts  on  various 
ayatem  performance  characteristics.  By  using 
different  class  Instances  the  development  team  oan 


determine  what  affact  substituting  one  Instance  for 
another  haa  on  total  system  performance.  GENESIS 
manages  tha  aoftwart  configurations  for  the 
different  desa  Implementations  (lnstanoea). 

If  your  typical  software  development  projects 
better  fit  the  Spiral  Model  [BOENM?,  where  the 
phases  depicted  in  the  Waterfall  Model  ere  iterated 
N  times,  then  the  GENESIS  tool  should  prove  even 
more  valuable.  An  Iteration  through  the  spiral  oan 
involve  GENESIS  at  many  different  levels.  At  the 
least,  GENESIS  will  be  used  to  re-integrate  the 
various  software  components.  In  a  more 
comprehensive  iteration,  tha  selected  Ada  ecmpller 
may  hava  been  replaced  with  another  —  requiring 
redefinition  of  ARTSE  olaasea  and  lnatancea  to 
natch  the  new  caapller'a  run-time  ayatem.  It  la 
antleipmtad  that  the  moat  frequent  utilization  of 
GENESIS  in  iterations  through  the  spiral 
development  process  would  be  the  lapl Mentation  or 
modification  of  alternative  instances  and,  leas 
froquantly,  tha  daflnltion  of  additional  olaaaea. 

In  aummary,  GENESIS  supplements  the  traditional 
aoftwart  development  llfe-oyole  in  much  the  same 
manner  as  othar  reuse  support  tools  with  one  very 
important  addition.  Although,  tone  additional 
•ffort  is  required  In  the  early  stages,  GENESIS 
should  payoff  over  tha  antlra  llfa-cyola  through: 

1.  Productivity  lr.creaaea  through  rtuae,  and 

2.  Reduced  developeent  risk  through  multiple 
instances. 

The  potential  for  risk  reduction  by  supporting 
multiple  development  paths  for  tha  ami  general 
class  of  functionality ,  makaa  GENESIS  a  unique 
aoftwart  rauat  and  tailoring  tool  for  Ada 
developeant. 

LESSONS  LIAENED  AND  OBSERVATIONS 

Our  work  on  GENESIS  has  resultad  in  lessons  end 
observations  that  can  easily  be  categorized  as 
davelopment  support  system  issues  and  GENESIS 
technology  Issues.  first  a  discussion  c f  the 
letter. 

STANDARD  ARTS!  UTIBFACKS.  Because  run-time 
interfaces  are  not  uniform  across  different 
compilation  systMS,  a  Custom  Build  Tool  (tha  part 
of  GENESIS  that  performs  tha  ocmpllar  specific 
application  build)  must  be  developed  for  each 
unique  sat  of  ARTSE  interfaces.  Acceptance  of  an 
ARTSE  interfacing  standard  such  aa  tha  proposed 
ABTEVG  framework  would  be  a  big  step  in,  not  only 
Increasing  the  utility  of  GENESIS,  but  of  opening 
embedded  systems  to  greater  tailorabllity , 
portability  and  reusability. 

INSTANCE  SELECTION  COLLISIONS.  Because  the  GENESIS 
class-instance  structure  is  very  flexible,  it  is 
possible  for  more  than  one  instance  to  utilize  the 
same  Ada  paokage  specifications  and  body 
alternatives.  It  is  possible  that  two  different 
body  implementations  from  separate  selected  class 
instances  may  be  included  in  a  user's  session. 
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Thla  would  reault  In  a  system  that  does  not 
faction  aa  expected  alnco  the  laat  tody  cospilcd 
would  be  the  one  used  ly  both  elaaaea.  Currently, 
thla  laaue  la  not  addressed  by  GENESIS,  rotentlal 
aolutlona  Include:  prcenj'M r-*r  the  uaer  to  aelect 
only  one  of  the  bodice  or  aodifiostlon  cC  the 
aource  code  to  allcw  use  of  both  lnatancea.  The 
former  solution  ia  obviously  the  easier  cf  the  two. 

CLA53-IE3TANCX  node,  scrrom  TAXLOEABILXn  AND 
reuse.  We  quickly  discovered  that  the  dnas- 
instance  model  we  structured  to  support  ARTSE 
tailorabllity  was  equally  applicable  to  support  the 
tailorine  of  any  donain  of  software.  In 
retrospect,  thla  should  have  been  expected  since 
one  of  the  desirable  attributes  of  object-oriented 
prop-amming  lenguagas,  such  aa  Smalltalk,  la  the 
inheritance  mechanism  which  supports  tailoring 
while  encouraging  reuse. 

CLASS-INSTANCE  MODEL  ENCOURAGES  INTERFACE 
STANDARDIZATION.  Gy  using  the  class  concept  to 
encapsulate  abstractions,  CDiESTS  helps  to  enforce 
the  standardisation  of  software  interfaces  while 
permitting  flexibility  in  implementation.  Using 
abstract  data  types  aa  an  exanple,  a  standard 
interface  to  a  stack  class  could  be  defined. 
Several  instances  fcr  the  stack  would  then  be 
lspleaented  following  Enoch's  taxonomy  [BOOC87]. 
The  different  instances,  implementing  bounded, 
unbounded,  concurrent,  nonconcurrent,  etc. 
variations  on  the  stack  data  typo,  would  all  have 
the  same  interface  for  users  of  tha  elaaa. 

CLASS-INSTANCE  MODE.  CAN  HJLF  REEUCT.  RISK.  Gy 
concurrently  developing  nultiple  ac-lutlona  to  the 
aase  class  of  functionality,  projects  can  reduce 
the  risk  cf  any  one  solution  will  fall.  The  class- 
instance  model  employed  by  GEHESYS,  facilitates 
this  risk  reduction  by  supporting  multiple 
instances  for  the  sane  class.  If  at  any  tine 
during  developsent,  any  coo  instance  is  shown  to 
fall,  or.e  of  the  retaining  instances  can  be  used. 
During  final  testing,  the  instanco  that  best 
provides  tho  required  functionality  can  be 
selected.  This  paradic?  encourages  the  dovdopsent 
cf  Innovative  aolutlons  in  conjunction  with  reusing 
tried  aolutlona  or  developing  cuatcnlsed  versions 
cf  tried  solutions  without  placing  the  project  at 
unacceptable  risk. 

The  development  support  syatroa  issues  include 
threo  specific  aroas:  Ada  ccapiler  and  aupporl 
dcvelofcont  toola,  X  wlndowa  and  X  Hay  tool  id t  and 
relational  databeso  management  system  (RD6K3). 

ADA  OOMFILER.  The  Alsys  Ada  coapllar  for  the  Sun  3 
foolly  cf  workstatlcns  was  generally  adequate.  An 
lntcreating  observation  was  that  large  aource  fllea 
that  were  coapllable  with  the  Alsys  compiler  on  an 
IBM  PC-AT  were  too  large  for  the  Sun  veraion. 
Occasional  problcas  with  the  pregraa  librarlea 
occurred.  The  problcoa  reaultcd  in  an  unusable 
library  which  required  tho  roceopilaticn  of  all 
code.  It  was  notod  that  if  a  caapilation  was 
aborted  by  the  uaer  (control -C),  the  user  took  tho 
chance  cf  corrupting  the  prop'aa  library. 


X  WINDOWS  ADD  TNE  X  RAT  TOOLKIT.  The  X  windowing 
environment  provides  a  pcrUble  window  and  graphic 
environment.  However,  the  X  11.2  distribution  from 
MIT  auffered  f rca  performance  problems.  The  X 
enviroment  is  made  eaaier  to  program  through  a 
toolkit.  We  employed  the  X  Ray  toolkit  since  we 
had  available  an  Ada  binding  for  it  from  SA1C  (also 
a  STARS  Foundation  product).  The  X  Ray  toolkit  had 
poor  documentation  and  the  Ada  binding  had  acvtral 
bugs.  (It  should  be  noted  that  SAIC  did  an 
excellent  Job  in  making  the  binding  available 
quickly  for  the  rest  of  the  STARS  community  and  in 
aupporting  other  STARS  contractors.)  Finally,  the 
X  Ray  toolkit  did  not  provide  widgets  fcr  the  types 
cf  uindow/graphlcal  objects  that  would  have  been 
better  auited  for  the  GENESIS  user  Interface.  If 
time  permitted,  we  could  have  written  our  own 
widgets. 

RELATIONAL  DATABASE  MANAGRMOTT  3 73 TIM  —  ORACLE. 

Use  cf  the  rro*C  programmer's  Interface  to  the 
Oracle  RCOKS  was  successful.  The  only  problems 
encountered  were  the  usual  nvancos  associated  with 
a  misunderstanding  between  tho  documentation  and 
the  programmer's  interjreution.  Surprisingly,  no 
aerioua  problems  were  encountered  in  using  the 
Grade  RECKS,  C  aubroutinea  and  the  Ad*  run-tiee 
enviroment. 
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ABSTRACT 


Many  studies  Involving  the  Ada  program¬ 
ming  language  rely  on  simplistic  examples  to  incor¬ 
porate  a  solution  space.  Inc  given  study  is  based  on 
data  security,  considered  to  be  a  high  priority  with  many 
software  engineering  researchers.  'Die  OILS  (Data  Encryp¬ 
tion  Standard)  was  the  major  focus  of  the  analysis. 


/.  Introduction 


The  necessity  so  use  cryptography  in  order  to 
protect  stored  and  transmitted  data  from  intruders  and 
eavesdroppers  has  been  recognised  in  many  applications 
such  as  clcetrome  funds  transfer,  automated  clear¬ 
inghouses,  and  securing  non-ofikial  computerised  mili¬ 
tary  data. 

In  1973,  the  U.S.  National  Bureau  of  Standards 
responding  to  public  concern  about  the  confidentiality  of 
computerized  data  outside  military  and  diplomatic  chan¬ 
nels.  invited  tlte  submission  of  data  encryption  techniques 
as  the  first  step  toward  an  encryption  scheme  intended 
for  public  use. 

The  method  selected  by  the  bureau  was 
developed  bv  IBM  researchers.  Known  today  as  the  Data 
Encryption  Standard,  it  was  issued  in  January  1977  as  the 
Federal  Information  Processing  Standard  Publication 
(FIPS  PUP)  46.  It  is  also  known  as  ANSI  standard  DEA 
since  1981  (ANSI  1980)  and  it  is  already  in  use  in  many 
industrial  applications.  In  recent  years,  the  DES  has  been 
proposed  as  an  ISO  (International  Standard  Organization) 
standard  under  die  name  of  DEA1  (ISO, 1983). 

Federal  agencies  and  departments  needing  such 
protection  can  purchase  commercial  DES  implementations 
that  have  been  validated  by  the  National  Bureau  of  Stan¬ 
dards  as  conforming  to  the  standard.  Software  implemen¬ 
tations  do  not  comply  with  the  standard  and  are  generally 
inefficient  as  compared  to  the  hardware  versions.  The 
software  implementations  can  still  provide  adequate  sup¬ 
port  to  many  hardware  systems  in  the  eases  where  prob¬ 
lems  with  the  cryptographic  unit  results  in  a  loss  of  in¬ 
tegrity  of  the  encrypted  data.  It  is  clear  that  although  the 
step-by-step  DES  algorithm  is  available  in  the  public 
domain,  the  mathematical  reasoning  behind  the  DES  algo¬ 
rithm  is  considered  confidenu'al  by  the  NBS. 


2.  Project  Scciutrlo 


In  the  context  of  this  report,  the  DES  system 
will  provide  cryptographic  support  to  a  number  of  ‘in¬ 
flight"  rockets  (via  a  DES  integrated  chip).  The  direction 
and  position  data  of  each  rocket  is  required  to  be  secure 
from  eavesdropping  by  the  potential  enemy.  In  addition, 
the  DES  system  will  incorporate  a  software  support 
mechanism,  whereby  the  integrity  of  the  DES  system  can 
be  verified.  This  requires  that  the  DES  software  support 
mechanism  provide  encryption/decryntion  operations  in  a 
‘stand  alone"  fashion  when  severe  hardware  failures  oc¬ 
cur  during  the  communication  linkage  of  the  ‘in-flight" 
rockets. 


3.  Scope 


The  DES  system  was  implemented  in  the  Ada 
programming  language.  The  hardware  and  software  im¬ 
plementations  focussed  upon  an  "Ada  only"  philosophy 
throughout  the  development  life  cycle  of  the  project.  The 
goals  of  the  project  include: 


*  Verify  the  design  impact  that  Ada 
has  on  program  development  using  the 
Ada  implementation  of  the  DES  algo¬ 
rithm  as  a  complex  model. 


*  Develop  an  appreciation  for  die 
performance  issues  involved  in  the 
development  of  Ada  real-time  pro¬ 
jects. 


*  To  incorporate  an  Ada  in-line  code 
emulator  to  understand  how  it  can  be 
used  in  the  dcvclopntcnt  of  Ada  dis¬ 
tributed  systems. 


*  To  gain  insight  into  the  hardware 
implications  that  pertain  through-  out 
Ada  project  developments. 
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•f.  Analysis  of  The  DES  Algarith/n 


Tlic  DUS  l*  a  single  key  jysicm  in  which  thus 
is  both  encrypted  and  decrypted  with  the  same  key,  a  se¬ 
quence  of  cigltt  numbers,  each  between  zero  and  one- 
twenty-seven.  The  algorithm  divides  a  bit  message  into 
blocks  of  eight  characters,  then  enciphers  them  one  after 
another  under  the  control  of  a  sixty-four  bit  key.  The 
letters  and  numbers  of  each  block  arc  scrambled  no  fewer 
than  sixteen  times  resulting  In  eight  characters  of  cipher 
text. 

•Dte  DUS  is  immune  to  brute  force  attacks 
since  it  would  take  a  machine  computing  one  million  tri¬ 
als  per  second  over  a  millennium  to  cover  ail  of  tire  72 
quadrillion  possible  keys.  HIM  and  the  National  Bureau 
of  Standards  warn  against  employing  around  200  of  the 
DOS's  keys  since  those  keys  are  considered  semi-weak 
keys.  A  semi-weak  key  is  any  key  that  might  ercatc 
dues  in  an  encrypted  message  that  could  lead  to  its  deci¬ 
pherment  in  less  time  than  a  brute  force  attack  would 
consume. 


5.  Development  Background 


The  development  method  utilized  in  this  pro¬ 
ject  is  that  of  the  "Bottom-Up"  method  of  software 
design.  In  this  methodology,  the  lowest  level  modules  are 
the  ones  to  be  designed  and  coded  first  in  the  develop¬ 
ment.  Succeeding  modules  are  then  designed  in  a 
hierarchical  fashion  until  the  progression  towards  the 
main  module  is  complete.  This  methodology  was  chosen 
because  of  the  abundance  of  independent  low-level 
modules  (without  much  up  front  design  overhead)  that 
were  required  to  be  implemented  in  the  early  phases  of 
the  DES  system  project. 


S.l  Softwtre  Development  Background 


The  software  DES  subsystem  is  based  upon  the 
standard  DES  algorithm  for  motivation  in  its  implementa¬ 
tion.  The  most  important  cryptographic  function  em¬ 
ployed  by  the  DES  algorithm  is  the  product  transforma¬ 
tion.  It  consists  of  successive  applications  of  substitution 
and  transposition  ciphers.  Transposition  ciphers  involve 
an  encryption  procedure  that  changes  the  normal  pattern 
of  the  characters  in  the  original  plain  text  message.  Sub¬ 
stitution  ciphers  on  the  other  hand,  replace  blocks  of 
characters  with  substitutes. 


$2  Hardware  Development  Backgrountl 


The  target  system  is  an  Intel  integrated  Circuit 
Emulator  unit  (ICE),  where  the  Ada  code  is  generated  on 
a  MieroVax  II  using  the  DDC-I  8086  Ada  eross-compilcr. 

The  ICE  unis  was  selected  as  the  target  to  fa¬ 
cilitate  lltc  optimizing  and  debugging  of  real  time  Ada 
code.  The  Digital  Encoding  chip  (WD2QC03A)  is  con¬ 
nected  to  a  serial  port  on  the  ICE  unit. 

The  Western  Digital  device  will  be  programmed 
to  use  tl>c  Cipher  Block  Chaining  mode  to  provide  secu¬ 
rity  to  the  system's  transmissions.  Once  the  Digital  En¬ 
coding  chip  has  been  Initialized,  the  system  is  then  ready 
to  encrypt  or  decrypt  messages.  The  Western  Digital 
Encoding/Decoding  chip  necessitates  that  its  data  register 
(including  the  application)  receive  one  byte  of  data  at  a 
time  in  groups  of  eight.  This  requirement  is  achieved  by 
the  use  of  the  function  Unchcekcd_Con version  which 
converts  the  bit  pattern  of  the  source  to  that  of  the  target 
(utilizing  the  same  amount  of  memory)-  These  messages 
may  originate  from  the  rocket  subsystem  or  from  the 
rocket  command  subsystem. 


6.  System  Doclopment 


The  development  of  the  DES  system  incor¬ 
porates  the  hardware  and  software  implementations  of  the 
DES  standard.  The  duality  between  the  hardware  and  the 
software  DOS  subsystems  allows  the  overall  system  to  an¬ 
ticipate  a  high  degree  of  integrity.  Thus  a  task  BIT  (Built 
in  Test)  will  check  the  operational  integrity  of  the  pri¬ 
mary  mode  of  the  DOS  system  (i.c.  hardware)  to  that  of 
the  secondary  mode  (i.c.  software).  Obviously,  the 
software  mode  will  offer  the  customer  (i.c.  "in-flight" 
rocket)  a  decreased  throughput  that  is  directly  proportion¬ 
al  to  lltc  number  of  customers  that  are  requesting  service 
in  the  given  time  interval. 


6.1  Software  System  Development 


Tlie  software  subsystem  consists  of  four  Ada 
packages  (about  900  lines)  providing  direct  and  indirect 
support  to  the  application  DES  module.  The  software  sub¬ 
system  is  designed  to  handle  words  (i.c.  16  bit  values)  in 
the  range  of  -32767  to  +32767  of  bamjypc.  (arbitrarily 
classified  as  bamjypc  but  identical  to  the  integer  type 
found  on  many  P.C.  implementations)  All  data  must  be  of 
lltc  said  type  (or  converted),  before  the  given  data  can  be 
processed.  The  cnctypiion  key,  External  or  Internal,  must 
be  incorporated  into  the  system  before  the  key  can  be 
processed,  and  thus  before  any  encryption  can  occur. 
Note  that  the  data  to  be  encrypted  is  considered  to  be 
processed  in  a  sixty-four  bit  envelope  (i.e.  four  words) 
with  zeroes  being  employed  as  padding  if  the  submitted 
data  envelope  falls  short. 
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6.1.1  Development  Structure 


Package  Kockct_Typc*  ■>  (50  Lines)  defines  ihc  mater 
Jaw  types  that  are  10  be  employed  by  the  rocket 
scenario  model. 

Package  Utility.  P^kage  ■>  (83  Lines,  2  procedures,  3 
functions)  consists  of  specified  DBS  types  and  atomic 
modules  that  are  to  be  employed  by  the  DBS  architec¬ 
ture. 

Package  SW_DE5_Paekagc  ■>  (201  lines, 4  procedures) 
the  upper  level  package  that  provides  encrypt/decry  pi 
DBS  functions  in  a  variety  of  envelopes. 

62  Hardware  System  Development 


The  first  module  to  be  designed  was  the  pro¬ 
cedure  responsible  for  the  initialisation  of  the 
WD20C03A.Thc  reccivcing  and  sending  of  information  to 
port  addresses  was  xcomplishcd  through  procedures  in 
the  DDC-  1's  Low  .lx  vc  I  JO  pxkagc,  Receive  jTomrol 
and  Scnd_Control.  (Since  there  arc  no  built-in-features  in 
Ada  to  handle  bit  manipulation,  a  procedure  was  designed 
to  handle  this  requirement  using  the  Ada  Mxhinc.Codc 
package) 

in  the  next  level  of  design,  there  is  a  task  which 
allocates  the  DBS  resources  for  either  guidance  or  posi¬ 
tion  data.  After  insuring  the  first  call  to  the  task  is  for  an 
encryption,  the  task  loops  indefinitely  allocating  resources 
for  either  encrypting  or  decrypting. 

The  next  level  is  the  Built-in-  Test,  BIT.  This 
level  supplies  the  integrity  testing  of  the  hardware  Digital 
Encoding  chip  by  verifying  the  hardware's  results  against 
those  derived  from  a  software  emulation  of  the 
hardware's  algorithm.  At  a  prc-dclincd  interval,  BIT  will 
test  hardware  integrity.  If  an  error  is  detected,  BIT  will 
switch  requests  for  encryption  /  decryption  to  the  software 
emulation  pxkagc. 


7.  Status  of  Development 


7.1  Status  of  Software  Development 


The  Software  DES  Subsystem  has  been  tested 
against  a  detailed  step  by  step  example  (see  Katzan,86). 
The  time  and  effort  required  to  develop  "In-House"  multi¬ 
ple  test  examples  was  found  to  be  too  costly  in  both 
respects,  instead  a  simplification  in  the  testing  process 
was  implemented.  Many  variations  of  tlie  sixty-four  bit 
text  anti/or  key  were  tested.  The  assumption  being  that  if 
the  software  subsystem  can  decipher  the  previous  cipher 
message,  then  the  system  can  be  deduced  to  have  some 
degree  of  integrity  (only  if  the  system  was  proven  to  be 
working  against  a  known  example  as  is  the  case). 


The  software  DES  subsystem  provides  an  en¬ 
cryption  time  of  0.679  seconds  for  sixty-four  bits  (four 
words)  of  data.  Encrypting  the  position  data  for  five  rock¬ 
ets  took  3.46  seconds,  and  encrypting  the  guidance  data 
for  the  five  rockets  took  3.67  seconds.  (The  MicroVax  It 
and  the  DDC-I  compilers  were  utilized).  P.C.  versions 
were  also  implemented  which  resulted  in  a  decrease  in 
performance  levels  as  expected.  (  22%  slower  on  the  PC- 


7.2  Status  of  Hardware  Development 


A  few  inconsistencies  with  the  DDC-I  Ada 
compiler  have  resulted  in  the  hardware  being  untested. 


These  inconsistencies  arc : 

I.  When  the  code  for  a  cenain  pxkagc  was  en¬ 
closed  in  a  single  file,  the  compiler  stated  that  the  library 
was  loo  smalt  and  that  a  new  sub-library  needed  to  be 
created.  This  error  message  occurcd  when  writing  the  ob¬ 
ject  code  into  the  library.  The  same  code  with  the 
modules  in  separate  files  compiled  successfully  into  the 
library. 

II.  The  use  of  Ada  generics  resulted  in  the  ina¬ 
bility  to  compile  cenain  procedures  needed  for  the  termi¬ 
nal  drivcrflnability  to  distinguish  generic  pxkagcs  of 
overloaded  procedures).  Compiler  stated  the  second  pxk¬ 
agcs'  procedures  already  existed  in  the  library. 

HI.  The  DDC-I  compiler  defines  "Byte"  to  be  a 
"new  integer",  which  states  that  "byte"  will  take  up  two 
bytes  of  memory  instead  of  one  byte  as  expected.  This 
caused  problems  with  some  of  the  procedures  in  the 
LowJxvclJO  pxkagc. 


As  a  side  note,  since  the  target  system  did  not  come  with 
a  monitor/keyboard  for  input/output  during  program  exe¬ 
cution.  a  terminal  driver  has  been  wntten  using  the 
DDC-I's  TenninaLDriver  pxkagc. 


S.  Conclusion 


Once  the  system  is  executing  as  designed,  the 
current  target  system  can  become  a  test  bed  for  more  ex¬ 
periments  in  tlie  real  time  arena  of  Ada  applications.  The 
attitude  of  this  group  has  been  to  unravel  these  unfore¬ 
seen  problems  rather  than  by-pass  them.  This  attitude  al¬ 
lows  programmers  to  observe  the  limitations  of  Ada  in 
the  real  time  environment.  Obviously  this  is  the  inception 
of  this  project,  the  real  significance  will  cook  when  tlie 
system  is  ported  from  a  single  processor  system  to  a  mul¬ 
tiple  processor  system  with  minimal  restructuring  effort. 
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9.  Further  research 

The  area  of  porting  a  program  structured  for  a  jingle 
processor  system  w  one  of  multiple  proccjjont  haj 
numerous  possible  utilizations  in  the  real  rinse  field. 
Also,  (he  inconsistencies  in  the  DDC-I  Ada  cross* 
compiler  can  be  analyzed  for  definitive  causes,  at 
present  there  can  only  bit  suppositions  as  to  the  actual 
causes.  In  addition,  the  software  encryption  modules  can 
be  utilized  in  the  field  of  Ada  benchmarking.  The  com¬ 
plexity  of  (he  DOS  algorithm  docs  incorporate  many  basic 
and  complex  Ada  features.  The  vision  of  standard  bench¬ 
marks  that  rates  certain  Ada  environments  by  their 
respective  DES  throughputs  in  cps  (encryption s/scc) 
can  be  of  a  valuable  asset  toward  the  evaluation  of  such 
environments. 
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FIG.  1  OES  CONTROL  SYSTEM 


FIG.  2  DES-SYSTEH  MOOEL 


FIG.  5  DES-SYSTEM  STRUCTURE  DIAGRAM 
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A  Hardware  Independent  System 
Development  Approach  Involving  Ada 

Tom  Dale 

Unify*  Defense  System* 

McLean,  V,\ 


Abstract 

This  paper  presents  lessons  learned  from  a  C3I  project 
employing  rapid  prototyping  and  object-oriented 
programming.  The  project  goal,  to  develop  a  hardware- 
independent  prototype  implementation  of  an  advanced  text 
(aka  message)  handling  system,  necessitated  a  software 
development  strategy  consisting  of  X  Window,  I'OSIX, 
NFS/TClVlP/Ethcreet,  SQL,  Ada,  and  C.  This  paper 
relates  lessons  learned  about  rapid  prototyping,  reusability, 
attaining  hardware  independence,  designing  a  distributed 
architecture,  using  Ada  in  a  multilingual  environment, 
tuning  the  performance  of  Ada  application  code,  and 
integrating  COTS/NDI  within  an  Ada  environment. 


1.  Introduction 

Ada  has  gained  increasing  acceptance  for  usage  in  nor- 
embedded  mission-critical  applications.  However,  Ada  is 
not  the  only  "standard"  currently  receiving  Government 
acceptance.  A  plethora  of  other  standards  have  also 
received  certain  notoriety,  such  as  Network  File  System 
(NFS),  Stnictuicd  Query  Language  (SQL),  Portable 
Operating  System  Interface  (x)  (POSIX),  Ethernet  (IEEE 
802.3),  along  with  others. 

Non-embedded  mission-critical  systems,  in  attempts  to 
reduce  system  costs  during  these  times  of  lean  budgets,  will 
employ  commcrcially-availablc  hardware  and  software 
where  feasible.  Attainment  of  hardware-independence 
further  requires  adherence  to  a  strict  suite  of  interface 
standards.  This  paper  describes  the  engineering  approach 
of  an  application  in  which  Ada  functions  as  one  element  of 
a  hardware-independent  v  ‘roach. 

This  paper  addresses  concerns  arising  from  developing  a 
working  prototype  text  handling  environment  consisu'ng  of 
Commcrcial-Ofl-The-Shelf  (COTS)  software  and  newly 
developed  code  written  in  both  Ada  and  C.  This  limited 
domain  description  parallels  work  underway  at  die 
Software  Engineering  Institute  (SEI)  regarding  domain- 
specific  architectures  but  differs  in  origination,  intent, 
emphasis,  and  scope. 


SEI  currently  investigates  message  handling  environments 
to  identify  “recurring  problems."  These  recurring  problems 
arc  evidenced  by  assigning  functions  to  threads  of  control 
and  noting  those  functions  represented  on  more  than  one 
thread. 

This  paper  describes  an  independent  industry  attempt  to 
develop  a  methodology  for  quickly  delivering  working 
prototypes  into  the  matkciplxc.  In  1987,  Unisys  Defense 
Systems  originated  an  IRAD  (Independent  Research  and 
Development)  project  to  develop  technology  for  quickly 
assembling  text  handling  environments  to  suit  a  wide 
variety  of  user*.  Message  handling  domain  experts  felt 
there  existed  a  better  way  to  develop  message  handling 
environments.  Tlic  project's  intent  was  to  quickly  develop 
a  working  prototype  satisfying  military  requirements,  not  to 
produce  a  strictly  Ada  solution.  This  work  may  be 
characterized  by  its  implementation  emphasis  on  1) 
ergonomics  with  system  requirements  developed  “from  the 
user  intctfxc  on  bxk"  in  an  integrated  application 
environment  and  2)  development  of  reusable  components 
designed  to  address  specific  implementation  concerns 
regarding  performance,  scalability,  and  configurability. 
The  scope  centered  on  providing  a  modular  design  that 
could  incorporate  emerging  technologies  (i.c.  permit  easy 
technology  insertion). 


2.  Business  Rationale 

This  IRAD  project  is  aimed  at  effecting  technology 
insertion  by  developing  text  handling  components  capable 
of  incrementally  replxing  existing  components.  Unisys 
Defense  Systems  based  its  rationale  on  the  fxt  that  the 
prototype  must  be  integrate  into  an  existing  system,  and  to 
provide  better  service  for  less  cost.  A  superior  product 
(working  prototype  or  not)  satisfying  mission  needs  not 
only  enhances  business  perceptions,  but  also  provides  users 
a  greater  capability  and  user  project  management  a  success 
story.  Tighter  budgets  pressure  the  military  to  replace 
obsolete,  expensive  to  operate  systems  with  modem 
hardware  and  software  which  will  increase  performance 
and  cut  costs. 

Unisys  Defense  Systems  realized  the  importance  of  a 
comprehensive  strategy  for  integrating  different 
components.  Open  Systems  are  software  environments 
comprising  products  and  technologies  that  are  designed  and 
implemented  in  accordance  with  vendor-independent, 
commonly  available  standards. 
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Ada  will  change  the  way  companies  do  business  with  DOO 
because  die  language  is  the  same  from  one  system  to 
another.  Across-the-board  use  of  Ada  provides  the 
competitive  edge  to  the  company  with  the  best  overall 
engineering  solution.  Separate  initiatives  within  DOD  to 
use  COTS  products  and  industrial  standards  wherever 
possible  also  reduces  the  potential  for  unnecessarily 
restrictive  competition.  It  seems  reasonable  to  Incorporate 
strengths  from  both  initiatives. 

3.  Approach 

Unisys  Defense  Systems  utilised  an  approach  predicated 
upon  the  development  of  a  hardware  independent  toolkit  of 
text  handling  components. 

Text  handling  conforms,  to  a  large  extent,  to  a  dataflow 
paradigm.  Problem  decomposition,  a  central  design  feature 
of  any  large  system,  whether  prototype  or  production, 
yielded  a  top  level  functional  decomposition  (ala  the 
structured  analysis  school  of  thought)  which  provided  a 
system  view  of  the  interconnecting  building  blocks.  The 
system's  working  scenario*  then  provided  system 
requirements,  operations  concept,  and  an  initial  thread 
design.  Those  threads  capable  of  utilizing  reusable 
components  were  selected  first  for  prototyping.  This 
Strategy  focused  the  prototype  effort  on  successively 
demonstrating  implemented  threads. 


3.1  Rapid  Prototyping 


Dynamic  and  transaction  processing  oriented  systems 
involving  extensive  user  dialogues  tend  to  be  the  best 
applications  for  rapid  prototyping.  A  rapid  prototyping 
methodology  allows  iterative  refinement  of  system 
requirements  tod  embedding  as  many  of  these 
requirements  as  possible  into  the  user  interface  to  build  the 
system  from  the  user  interface  backwards.  The  system's 
objects  resulted  from  this  iterative  prototyping  of  the  user 
interface. 

Two  major  types  of  life  cycle  models  for  prototypes  exist. 
In  one,  the  prototype  Is  regarded  as  a  throwaway  to  be 
discarded  when  the  real  production  system  is  implemented. 
In  the  other,  portions  or  all  of  the  prototypes  wind  up  as  the 
end  product,  actually  becoming  the  final  production 
system.  The  goal  of  a  prototype  typically  differs  from  that 
of  a  production  software  system  in  that  effective  use  of 
designer  time  and  rapid  user  feedback  have  greater 
importance  than  efficient  use  of  machine  resources, 
completeness,  and  robust  operation.  However,  given  a 
competitive  business  environment  without  the  luxury  of 
time,  business  strategy  dictated  development  of  a  prototype 
system  capable  of  replacing  existing  production  systems. 

No  sensible  manager  would  commit  to  rapid  prototyping 
armed  only  with  third  generation  compiled  languages  and 
some  batch  dau  management  utilities.  To  put  the  "rapid"  in 
the  prototype,  be  prepared  to  evaluate,  select,  and  purchase 
some  software  development  tools  that  could  be  quite 
expensive. 


Innovations  promising  big  payoffs  are  also  accompanied  by 
a  certain  degree  of  risk.  To  sell  management  on  the 
benefits,  you  must  also  be  in  a  position  10  spell  out 
precisely  how  you  intend  to  control  and  minimize  those 
risks.  A  distinction  should  be  made  between  change 
management  and  configuration  management.  Change 
management  tracks  the  changes  to  each  individual 
component  of  a  system.  Configuration  management  adds 
the  capability  to  organize,  manage,  and  track  all  pieces  of 
an  application  as  a  unit. 

Only  one  prototyped  function  could  not  become  part  of  a 
final  system.  One  function  was  prototyped  using 
5UNV1I-W  since  at  that  time  a  requirement  existed  for  a 
window-based  application  and  XI I  was  not  stable  enough 
to  use. 

Prototype  elements  haw  been  evaluated  to  identify 
potential  difficulties  in  deliverable  versions.  Statistics 
concerning  the  firing  frequencies  of  the  prototype's 
components  identified  potential  performance  bottler**  lot 

User  feedback  helped  to  evaluate  the  appropriateness  of  the 
prototype  design  concepts. 

3.2  Reusable  Components 

A  different  perspective  on  reusability  permits  design  of 
paramctcr-dnvcn  functions  as  reusable  software 
components  which  need  not  be  strictly  Ada  generics. 
Generics  are  used  where  applicable  to  effect  'Ada'  reuse 
(e.g.  dou  ./-linked  list  generic);  however  reusable  software 
components  reduce  both  development  and  maintenance 
risks.  These  reusable  software  components  correspond  to 
operations  performed  in  the  system  and  reduce  both 
development  and  maintenance  risks. 

Dataflow  and  control  flow  are  two  popular  decomposition 
criteria.  Components  of  a  dataflow  decomposition  are 
independent  sequential  processes  that  communicate 
through  buffered  dau  streams  (essentially  FIFO  queues), 
while  the  components  of  a  control-flow  decomposition  are 
procedures  that  are  called  by  and  return  to  a  main 
procedure  with  a  single  control  thread. 

High-auality  reusable  text  handling  components  are 
attainable.  It  is  important  to  have  a  relatively  complete  set 
of  general-purpose  components  to  perform  the  functions 
common  to  many  systems,  such  as  managing  displays, 
sorting  and  searching,  parsing  input  strings,  and  managing 
look-up  rabies.  Many  of  these  functions  can  be  effectively 
encapsulated  in  a  small  set  of  abstract  data  types.  It  is  very 
important  to  provide  generic  versions  of  the  reusable 
components  because  it  would  otherwise  be  impossible  to 
design  with  abstract  data  types  while  relying  on  standard 
reusable  components  for  performing  common  utility 
functions. 

A  strategy  based  on  reusable  software  components  is  a 
promising,  practical  approach  to  rapid  prototyping. 
Modularity  is  especially  important  in  prototyping  because 
of  the  need  to  make  many  changes  in  a  short  time.  A 
systematic  method  for  prototyping  is  nccessaty  but  not 
sufficient  for  the  rapid  construction  of  prototypes  for  large 
real-time  systems. 
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The  engine  concept  (atomicity)  evolved,  An  engine  5*  not 
machine-specific.  A  specialist  work*  on  an  engine  which 
allows  creation  of  new  features  without  having  to  split 
work  among  multiple  teams.  This  method  avoided  the 
tracking,  of  changes  required  should  a  layering  approach 
based  on  different  operating  environments  have  been  used. 

3.3.  Distributed  Architecture 

When  designing  a  distributed  architecture,  top  level 
functional  decomposition  allows  a  designer  to  obtain  a 
system  view  of  the  interconnecting  building  blocks 
describing  functional  (service)  requirements.  Resulting 
modularity  increases  productivity  by  reducing  debugging 
efforts  and  improves  understandability,  reliability,  and 
maintainability  of  developed  system  software,  features 
especially  important  in  rapid  prototyping. 

The  number  of  modules  affected  by  a  change  is  limited  and 
can  be  determined  by  a  straightforward  mechanical 
analysis  of  the  prototype's  dataflow  structure  and  thread 
delineation.  Distribution  of  computational  parts  among 
several  processors  becomes  easier,  since  implicit 
interactions,  difficult  to  implement  in  a  loosely  coupled 
architecture,  have  been  eliminated. 

The  trend  exists  toward  distributed  applications  based  on 
the  client-server  model.  When  multiple  users  access  a 
common  resource,  performance  becomes  a  critical  issue. 
Distributed  processing  Is  key  to  maintaining  top  server 
performance.  The  processing  potential  of  each  nctwotk 
node  should  be  exploited  instead  of  letting  the  server  do  all 
the  work.  One  solution  to  this  problem  is  to  use  a 
distributed  environment  based  on  low-cost  workstations. 
Rapid  advances  in  computer  hardware  have  allowed 
networked  PCs  to  become  an  alternative  for  many  military 
applications  once  reserved  for  mainframes  or 
minicomputers.  High-speed  80286-  and  80386-bxscd  PCs 
have  the  raw  computing  power  of  minicomputers. 

Interprocess  communications  also  allow*  applications  to 
send  messages  to  each  other  based  on  the  results  of  specific 
actions.  Servers  were  connected  (whatever  their  source 
language)  by  communicating  through  files.  Two  processes 
must  agree  on  the  interchange  protocol  which  adds 
complexity  but  allows  modularity.  Eventually,  such 
integration  code  wiU  be  performed  by  knowledge-based 
engineering  tools. 

3.4  Standards 

Standardization  and  openness  arc  taken  for  granted  in 
telephones,  telecommunications  swi'ches,  televisions, 
radios  and  compact  disk  players.  Whoever  the 
manufacturer,  all  these  devices  can  "talk  to  each  other"  and 
freely  interconnect. 

Standards  allow  users  to  move  forward  with  technology 
innovations  while  protecting  software  investments  and 
minimizing  training  time.  Standards  allow  software 
developers  to  concentrate  on  writing  applications  and 
solving  problems  at  hand.  Standards  provide 
transportability  across  various  platforms,  thereby  protecting 
a  software  developer's  investment. 


Standards  reduce  the  risk  of  obsolescence  and  reduce  cosu 
because  they're  supported  by  multiple  vendors.  They  also 
reduce  train-"''  service  and  support  costs.  Costs  associated 
with  $oflutaiw  re-writing,  staff  re-training,  and  loss  of 
access  to  bformation  are  monumental  when  users  arc 
required  to  move  from  one  proprietary  system  to  another. 
In  fact,  the  likelihood  is  slim  that  a  user  can  even  maintain 
and  reuse  alt  his  or  her  information  •*  years  of  collected 
data  --  after  a  major  change  in  hardware. 

Users  have  demanded  standardization  to  hook  together 
heterogeneous  computing  environments  so  that  application 
programs  can  move  between  different  operating  systems 
within  a  single  network. 

Once  standards  arc  accepted,  hardware  comparisons 
become  easier.  Standardization  reduces  product 
uniqueness;  it  can  also  increase  the  return  on  research  and 
development  investment.  As  the  software-hardware 
interface  becomes  more  standardized,  software  developers 
do  less  work  to  get  more  money.  Fewer  channels  will  be 
needed  for  manuring,  and  the  marketability  of  many 
software  products  will  be  enhanced  as  software 
applications  begin  to  run  on  more  types  of  hardware  and 
brxomc  marketed  through  wider  distribution  channels. 

Software  should  be  purchased  from  vendors  who  are  viable 
for  the  long  term  and  have  solid  migration  strategies.  Since 
these  vendors  provide  a  migration  path  as  standards  evolve 
through  multiple  permutations,  they  can  spread  the  burden 
of  migration  rewrites  over  the  entire  customer  base. 

Both  purchased  and  internally-developed  software  should 
be  written  in  languages  that  are  likely  to  continue  as 
standards.  In  addition,  code  generators  should  be  selected 
which  generate  standard  languages. 

This  rush  to  provide  users  with  the  standards  they  demand 
such  as  POSIX,  SQL,  and  Ada  docs  not  in  itself  provide  the 
foundation  for  viable  open  systems.  Vendors  must  provide 
these  standards  in  an  integrated  and  common  fashion  that 
assures  consistency  of  implementation.  Standards  are 
defined  with  allowances  for  implementor-defined  options, 
portending  different  "standard"  variations. 

3.4.1X11 

In  distributed  environments,  the  X  Window  System,  or 
XU,  developed  at  the  Massachusetts  Institute  of 
Technology  (MIT)  and  supported  by  the  X  Consortium, 

*  '  i-Hng  most  workstation  manufacturers,  offers  network 
transparency  and  unprecedented  portability  of  applications 
programs.  Applications  running  on  central  mainframes, 
minicomputers  or  other  workstations  can  display  results  on 
any  vendors'  local  workstations  running  the  XI 1  server. 

In  XI 1,  the  connection  is  made  over  the  network.  As  long 
as  an  application  is  capable  of  issuing  XU  protocol 
requests  over  the  network,  it  can  display  output  on,  or 
obtain  input  from,  any  device  on  the  network  that  is 
running  an  XU  server. 

Since  the  major  workstation  vendors  have  committed  to 
supporting  XU,  system  integrators  can  avoid  being  locked 
into  writing  their  applications  for  a  proprietary  windowing 
system  environment  and  can  choose  workstation  hardware 
from  any  vendor  to  support  their  applications  requirements. 
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The  XII  diem  application  U  nude  of  several  laycts;  the 
Xlib  programming  interface,  which  interfaces  with  MIT 
toolkits,  which  can  interface  with  high-level  graphics  (e.g. 
PHIG5,  GKS),  from  which  a  look  and  feel  can  be 
developed.  XII  doesn't  specify  the  look  and  fed  of  the 
user  interface;  it  simply  provides  a  set  of  tools  with  which 
to  build  one.  The  X  Toolkit,  which  includes  X  Toolkit 
Intrinsics  and  X  Widgets,  coouins  software  tools  for  X- 
based  applications  development.  The  look  and  feel  consists 
of  how  the  graphics  and  icons  align  on  the  screen  and  how 
the  toolkit  gets  called.  Ultimately,  a  user  interface  needs  to 
be  intuitive  to  be  valuable,  with  ’‘intuitive’*  meaning  menu- 
based  or  icon-based.  The  comfort  factor  of  the  user  with  an 
interface  is  what  determines  acceptance. 

The  diem  requests  graphics,  and  the  server  provides  them. 
The  server  can  be  local  or  on  a  different  type  of  CPU  on  the 
other  side  of  the  building;  the  user  doesn't  have  to  know. 
This  allows  applications  to  run  on  platforms  where  they  can 
run  best,  rather  than  being  restricted  to  the  workstation. 

3.4.2  POSIX 

The  term  POSIX  is  an  IEEE  trademark.  POSIX  aims  at 
making  the  independent  part  as  large  a  proportion  of  the 
whole  at  possible.  McCarron  (I]  provides  an  excellent 
compendium  of  POSIX,  pans  of  which  have  been 
paraphrased  fredy  and  included  herein.  Most  vendors  will 
meet  POSIX  standards,  albeit  some  grudgingly. 

The  issue  is  not  whether  we  will  reach  POSIX  compliance 
but  how  quickly  we  will  reach  POSIX  compliance.  POSIX 
attempts  to  effect  software,  hardware,  maintenance  and 
training  savings.  The  Government  has  assumed  the  lead  in 
open  systems  which  will  return  value  as  new  applications 
and  technology  become  available.  The  Government  desires 
computers  to  work  in  multivcndor  environments.  This 
goal  consists  of  three  pans:  portability,  interoperability, 
and  scalability.  Portability  enables  systems  -  even  those 
from  different  vendors  ■  that  meet  POSIX  specifications  to 
uk  the  saipe  application  software.  Interoperability  allows 
the  computers  to  work  together,  and  scalability  means  that 
different  sizes  of  computers  -  from  personal  computers  to 
supercomputers  •  can  exist  in  the  same  software 
environment. 

The  POSIX  IEEE  1003. 1  standard  is  a  Unix-based 
operating  system  interface  designed  to  provide  portability 
of  applications  software  at  the  source  code  level  by 
producing  a  System  Services  Interface  standard.  P1003.1 
defines  a  set  of  system  calls  and  library  routines,  some  of 
which  arc  optional.  It  docs  not  address  operations  such  as 
urer  commands. 

NIST  created  the  initial  POSIX  Federal  Information 
Processing  Standard  151  (FIPS  151)  to  give  government 
buyers  a  set  of  specifications  to  uk  before  IEEE  formally 
adopted  1003.1  from  which  POSIX  FIPS  151  differs  in 
small  substantive  ways.  Many  of  there  differences  are 
generational  since  the  FIPS  is  based  on  Draft  12.0  of 
P1003.1,  while  the  final  standard  is  based  on  Draft  13.0. 
NIST  is  now  committed  to  revising  the  FIPS  and  bringing 
it  into  line  with  Draft  13.0.  P1(X)3.1  is  expected  to  be 
adopted  by  ANSI  and  ISO  making  it  an  international 
standard  in  1989. 


Hie  IEEE  standard  offers  some  options  mandated  in  the 
FIPS.  In  some  instances  where  the  full-ure  standard  offers 
a  choice  for  implementations,  NIST  has  selected  one 
choice  to  ensure  application  portability.  The  resulting  FIPS 
requires  vendors  to  meet  a  more  demanding  specification. 
This  unilateral  move  by  NIST  on  POSIX  is  a  departure 
from  its  tradition  of  waiting  for  vendors  to  adopt  standards 
before  drafting  federal  versions  of  those  specifications. 

NIST  has  another  effort  underway.  With  the  help  of 
X/Open,  it  has  developed  a  proposed  family  of  next- 
generation  standards  catted  the  Applications  Portability 
Profile  (APP).  The  APT  addresses  POSIX  bindings,  or 
links  between  applications  and  POSIX  specifications,  for  a 
host  of  functions,  including:  databare  management;  data 
interchanges  for  document  processing,  graphics  and 
product  data;  network  service*  for  data  communications 
and  file  management;  and  hooks  to  support  different 
computer  languages  (C,  COBOL,  Pascal,  FORTRAN  and 
Ada). 

The  IEEE  FOSIX  committee  has  recently  formed  a 
subcommittee,  called  the  P1003.0  group,  chartered  with 
defining  a  portable  operating  environment,  similar  to  the 
NIST  effort.  Pl003.0's  objective  is  to  integrate  vanous 
application  s>andards  (windowing  systems, 
communications,  programming  languages,  databare  access, 
graphics  and  user  interface)  with  TOS1X  and  each  other  to 
create  a  public  domain  open  systems  environment  as  robust 
as  a  proprietary  system  environment. 

P1003.2,  Shell  and  Tools  Interface,  defines  a  programmatic 
interface  for  shells,  tools,  and  some  commonly  found  Unix 
utilities  like  awk,  grep,  Ip,  trace,  etc.  The  command  ret 
was  frozen  in  March  1988  with  the  standard  shell  and  tool 
interface  expected  late  in  1989. 

PI003J.  Ada  Binding  for  PI003.1,  will  develop  language- 
independent  representations  of  each  service  described  in 
P1W3.1  so  that  Ada  representations  may  be  established. 
P1003.1  is  based  on  C. 

Other  POSIX  efforts  include  PI003.3.  Testing  and 
Verification,  P1003.4,  Real  Time,  and  P1003.6,  Security. 

POSIX  and  the  System  V  Interface  Definition  (SV1D)  test 
suite  for  Unix  System  V  compatibility  overlap.  Roughly 
30  percent  of  the  SV1D  specifications  arc  nor  included  in 
POSIX,  while  about  50  percent  of  POSIX  is  not  found  in 
the  SV1D.  AT&T  plans  to  make  release  4.0  of  Unix 
System  V  -which  is  due  late  next  ycar-POSIX-compliam. 

3.4.3  NFS 

NFS  provides  transparent,  remote  access  to  filesystems. 
NFS  uses  an  External  Data  Representation  (XDR)  to 
describe  its  protocols  in  a  machine  and  system  independent 
way.  NFS  is  implemented  on  top  of  a  Remote  Procedure 
Call  (RPC)  package  to  simplify  protocol  definition, 
implementation,  and  maintenance  since  RPCs  arc 
synchronous.  NFS  uses  a  stateless  protocol  to  facilitate 
crash  recovery.  NFS  does  not  support  all  of  the  Unix 
semantics. 
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It's  not  uncommon  to  find  *  network  with  10  to  12 
workstations  on  Ethernet  being  slowed  down  due  to 
bandwidth  limitations,  making  suitable  NFS  performance 

Sucstionabk,  An  Ethernet  can  be  divided  into  smaller 
cpartmcntal  systems  with  a  faster,  broadband  or  Tiber 
cable  connecting  them  these  communities  of  interest.  Such 
“internetworking"  will  be  a  key  issue  for  network  managers 
in  the  near  future  as  well  as  long  term.  A  Fiber  Distributed 
Data  Interface  (FDD1)  network  has  transmission  speeds  of 
100  Mbps  and,  since  the  token  is  released  immediately 
after  transmission,  supports  circulation  of  multiple 
messages  on  the  network  simultaneously. 

3.4.4  SQL 

SQ1-,  developed  for  relational  databases,  represents  a 
method  to  manage  and  query  relational  databases.  SQL  is 
implemented  on  personal  computers,  minicomputers,  and 
mainframes.  Most  vendors  have  developed  SQL  supersets, 
More  recently,  vendors  have  implemented  distributed 
versions  of  their  SQL  systems.  Essential  integrated 
development  tools  have  beat  implemented  by  virtually  all 
vendors  to  support  relational  database  management  system 
(RDBMS)  application  development. 

Dr.  EF.  Cobb  invented  RDBMS  over  20  years  ago  at  IBM. 
In  1985,  he  published  12  rules  defining  RDBMS  in  an 
attempt  to  keep  the  term  “relational"  from  being  corrupted 
by  database  vendors.  The  ANSI  SQL  standard  falls  short 
of  recommending  a  RDBMS  as  defined  by  Dr.  Cobb.  For 
example,  ANSI  SQL  docs  not  offer  any  recommendations 
for  a  catalog  or  indexes  although  most  vendors  do  offer  this 
capability. 

Most  vendors  are  working  on  extensions  to  their  RDBMSs 
far  beyond  that  envisioned  by  Dr.  Cobb  or  those 
recommended  in  the  ANSI  standard.  Vendors  arc  now 
implementing  commands  for  the  manipulation  of  complex 
databases  including  digitized  voice,  bit-mapped  graphics, 
memoranda,  and  others. 


3.4.5  Ada 

Ada  has  been  mandated  for  use  in  developing  new  systems. 
The  term  “Ada"  includes  not  only  the  Ada  language  but 
also  the  environment,  software  engineering,  good  software 
tools,  configuration  control,  etc.  However,  anticipated  cost 
savings  from  the  use  of  Ada  are  not  being  realized. 

Ada  packages  arc  a  good  means  of  implementing  standard 
components.  Ada  packages  allow  a  superior  design 
approach  since  packages  can  encapsulate  both  data  and 
procedure  resources  required  to  implement  a  client/server 
mechanism. 

The  Ada  tasking  model  determines  how  and  in  whit 
sequence  program  tasks  arc  performed.  This  model  was 
designed  on  the  assumption  that  one  executable  Ada 
program  would  simultaneously  execute  many  tasks. 
Weaknesses  of  the  Ada  tasking  model  are  well-known  (2J. 
With  the  Ada  tasking  model,  users  cannot  clearly  specify 
particular  times  or  priorities  in  a  program.  Although  this 
operation  can  be  theoretically  achieved,  the  implementation 
typically  creates  a  large  system  overhead  that  slows  down 
performance. 


Ada  pragmas  allow  data  sharing  among  programs  and 
provide  interfaces  to  procedures  written  in  other  languages, 
such  as  Fortran,  C,  or  assembly.  This  inability  gives  users 
access  to  operating  jvjtem  facilities  and  supplies  a 
convenient  method  for  incorporating  real-time  features  in 
an  Ada  system.  At  the  same  time,  this  methodology  fulfills 
the  letter  of  the  Ada  language  requirements  but  maybe  not 
the  spirit. 

Ada  suppliers  now  provide  other  methods  to  deal  with  real¬ 
time  programs.  These  solutions  include  run-time 
environments  that  meet  real-time  requirements  but  stay 
within  the  limits  of  the  Ada  language.  Usually  these 
environments  provide  access  to  the  operating  system  of  a 
computer  through  Ada  packages  -  constructs  that  define  a 
related  group  of  type  definitions,  data  declarations, 
functions  and  procedures. 

Concurrency  is  possible  but  difficult  to  achieve  in  Ada. 
Users  need  a  way  to  define  tasks  that  are  divided  across 
multiple  processors.  To  do  this,  programmers  must 
determine  the  kinds  of  objects  each  processor  can  access, 
set  up  communication  between  processors,  and  identify  the 
data  that  must  be  accessed  by  each  processor.  Ada  was  not 
designed  to  meet  this  complex  programming  requirement, 
referred  to  as  the  definition  of  share  groups.  One  solution 
to  this  requirement  is  to  provide  a  mechanism  to  share  data 
between  Ada  programs,  relieving  the  user  of  the  low-level 
implementation  that  normally  occurs  with  shared  data.  A 
pragma  defines  this  package  as  a  shareable  data  pool. 

Ada  places  operating-system  functions  in  the  language. 
Ada  task  management  is  the  responsibility  of  the  Ada  run¬ 
time  environment  and  may  or  may  not  involve  UNIX 
process  management.  The  Ada  task  scheduler  sits  on  too  of 
the  UNIX  process  scheduler  which  lends  to  slow  things 
down. 

4.  Lemons  Learned 

4.1  Reusability 

Customers  merely  desire  fewer  defects  per  system.  Reused 
code  is  Invariably  better  quality  than  new  code  because  it 
has  already  been  "proven."  Reusable  software  building 
blocks  give  belter  quality,  a  unified  user  interface  across  a 
multiproduct  line,  and  better  speed  to  market. 

Reuse  can  be  defined  at  a  broader  level  than  just  Ada 
generics  to  create  “Software-lCs"  13). 

We  (the  royal  "we")  rue  close  to  providing  building  blocks 
for  a  user  or  applications-ptovider  to  easily  assemble  as  if 
they  were  a  single  integrated  application  from  the  outset. 

Reuse  guidelines  are  needed  including  definitions, 
distribution  mechanisms,  and  legal/licensing  criteria. 

4.2  Rapid  Prototyping 

Prototype  code  must  be  easy  to  read  and  analyze  because 
the  prototype  must  support  analysis  of  the  intended  system 
and  document  an  initial  design.  The  prototype  must  be 
easy  to  modify  because  it  will  be  subject  to  many  revisions 
before  the  user  is  satisfied  with  the  requirements  as 
reflected  by  the  prototype's  behavior. 
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It's  important  to  decide  in  advance  how  the  software 
development  process  will  be  managed  and  controlled. 
Unix  directory  structure  and  routines  provides  a  shell  script 
hierarchy  permitting  different  segregated  prototype 
instances. 

4.3  Multilingual 

A  multilingual  approach  provided  an  initial  operating 
capability:  existing  user  interface  software  had  been 
written  in  C  but  new  functions  were  implemented  in  Ada. 

The  use  of  Ada  in  a  multilingual  environment  required 
interprocess  communication  in  which  two  processes  agree 
on  the  interchange  protocol  via  files.  This  approach  added 
complexity  but  preserved  modularity. 

Unavailability  of  Ada-SQL  and  Ada-POSIX  bindings  and 
precocious  Ada-X  bindings  led  to  use  of  C  as  the 
integration  language.  A  sincily  Ada  software  environment 
is  desired;  however,  it's  Still  premature  to  expect  Ada  »o  be 
used  exclusively  when  rapid  prototyping  since  all  bindings 
have  not  been  definitiacd  and  disseminated.  E.g.  pragma 
u«tt  <  face  provided  *  C  interface  to  !*OSIX  for  scandir 

Particularly  problems  can  result  in  multilingual 
environments  word  boundaries  from  the  manner  that  Ada 
compiler  vendors  implement  type  record.  Not  all  vendors 
contiguously  allocate  space:  embedded  nulls  and  record 
layout  differences  have  been  uncovered  when  moving  the 
prototype  from  system  to  system,  Ada  compiler  to  Ada 
compiler.  The  Unix  od  utility  has  come  in  handy. 

4.4  Ada 

Per  proper  Ada  usage,  system  dependent  code  was  isolated 
in  packages. 

TEXT  JO  proved  cxhorbitamly  expensive  when  doing  text 
processing.  To  get  better  performance  (reduce  the  number 
of  TEXTJO  function  calls),  an  entire  message  was  read 
into  an  internal  buffer  using  GETJJNE.  Character  at  a 
time  reading  in  Ada  was  not  feasible 

ASCII.LF  was  used  to  give  an  end-of-linc  character  similar 
toC. 

UNCHECKED  CONVERSION  or  ASCII  text  characters 
outperformed  'FOS. 

4.5  Integrating  COTS/NDI  Software 

There  is  a  significant  difference  in  cost  between  an  item 
uniquely  manufactured  for  a  program  that  will  use  but 
small  quantities  and  a  commercially  available  equivalent 
whose  standard  manufacturing  process  includes  testing  to 
ensure  the  reliability  needed  for  a  tactical  or  strategic 
application. 

One  shortcoming  of  off-the-shelf  software  is  that  it  is 
generic.  Users  would  prefer  to  make  the  software  adapt 
more  to  their  needs.  This  is  quite  a  challenge  to  us 
developers,  to  uy  and  anticipate  the  many  different  ways 
our  programs  may  be  used  and  then  build  a  core 
architecture  that  will  support  that. 


COTS/NDI  software  should  be  considered  an  instance  of 
rapid  prototyping  which  provides  an  initial  operating 
capability.  If  COTS/NDI  software  runs  in  a  system-high 
environment  then  security  considerations  diminish. 

A  transition  plan  based  upon  incremental  changes  to 
existing  fielded  software  systems  can  transition  (one 
function  at  a  time)  from  current  source  languagc(s)  to  Adx 
During  the  transition,  the  system  must  be  supported  by  two 
software  environments,  the  one  currently  in  use  and  Ada. 

This  concept  is  based  on  an  established  philosophy  of 
system  test  engineering:  "whenever  possible  limit  the 
number  of  unknowns  to  ooc,"  During  the  transition  phase, 
the  system  remain*  fully  operational.  Only  one  function  at 
a  time  is  added  or  modified.  Thus  only  the  interfaces  to 
and  performance  of  that  function  need  to  be  considered 
during  the  software  updates. 

4.6  Interoperabitty 

Pull  file  path  name*  were  used  to  accommodate  NFS. 

During  prototype  development  SQL  was  decoupled  from 
client  applications  to  avoid  the  necessity  foe  licensing 
agreement*  when  demon*trating  the  prototype  on  different 
hardware.  Corporate  bureaucracy  indeed  affect*  software 
development  *ince  the  bureaucracy  is  not  primed  to  quickly 
process  licensing  agreements. 

5  Conclusion 

Non-embedded  C3I  systems  must  be  sealable  In  terms  of 
capacity,  storage,  and  physical  sixe  to  satisfy  site 
requirements  without  adversely  affecting  system 
functionality  and  response  time  capabilities.  1  Toper  design 
and  implementation  of  configurable  software  components 
assist  these  aims. 

What  Unix  gives  us  is  an  architecture  in  which  we  can 
integrate  multiple  architectures.  Despite  Unix  and  X 
Windows,  there's  still  dependencies  that  an  application  or 
systems  supplier  writes  into  a  system. 

Program  managers  must  enforce  software  discipline  and 
planning. 

Prototyping  and  reuse  constitute  a  more  productive 
approach  to  software  engineering.  Using  that  method, 
design  moves  away  from  a  traditional  top-down  approach 
to  something  more  iterative,  where  engineers  refine  the 
product  until  it  meets  specifications. 

Rapid  prototyping  is  particularly  effective  for  ensuring  that 
the  requirements  accurately  reflect  the  user's  real  needs, 
increasing  reliability  and  reducing  costly  requirements 
changes. 

Rapid  prototyping  is  not  the  universal  panacea  for  the 
vexing  software  development  problem.  Successful 
implementation  of  prototypes  is  highly  individualistic. 

Attaining  hardware  independence  (i.e.  portable  software) 
requires  disciplined  application  of  software  engineering 
techniques. 
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Some  of  (be  management  lesions  learned  regarding  Ada 
include:  reusable/poittabk  systems  cost  more  to  develop, 
Ada  projects  have  longer  design  phases,  but  shorter  coding 
and  integration  phases. 

Distributed  architecture  implementation  necessitates  if  not 
avoidance  then  judicious  use  of  Ada  tasking,  tf  Ada  is 
used  like  older  programming  languages,  the  results  are 
questionable. 

Proper  use  of  Ada  yields  reuse,  portability  and  maintenance 
benefits,  Shortcomings  include  the  lack  of  a  complete 
inventory  of  Ada  software  or  Ada  projects,  lack  of  a 
coordinated  effort  to  determine  the  benefits  of  Ada  and  the 
poor  dissemination  of  completed  research  on  Ada 
deficiencies. 
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Alntnct 

Thi*  paper  conceairate*  on  the  implementation 
of  blackboard  system*  In  Ad*.  It  describe*  the  black- 
Wnl  com  red  model  of  problem  solving,  a  generic  ap¬ 
proach  to  tb«  design  and  Implementation  of a  black¬ 
board  control  system,  and  tbe  application  to  a  classic 
defease  problem. 


1  Introduction 

There  i*  Increased  interest  in  implementing  artificial  Intelli¬ 
gence  application*  in  Ada.  Effort*  in  thi*  area  eneompas*  ex- 
jxrt  *y»tem*  (AdkS6.LaV3(i,JI«2§«),  distributed  knowledge 
baaed  system*  [HraSG.FraSC],  pattern  directed  processing 
[HKWS5],  semantic  networks  (SPASG),  reusable  heuristic 
.search  algorithms  jDobSS]  and  others.  This  pajrer  concen¬ 
trates  ou  the  implementation  of  biaekhcard  (HD)  systems  in 
Ada.  It  describes  the  blackboard  control  model  of  problem 
solving,  a  generic  approach  to  the  design  and  implementa¬ 
tion  of  a  blackboard  control  system,  and  the  application  of 
the  approach  to  a  classic  defeme  problem. 


2  Blackboard  Model 

A  problem  solving  model  U  *  scheme  that  constructs  a  solu¬ 
tion  by  organising  reasoning  step*  and  domain  knowledge. 
A  model  provides  a  conceptual  framework  for  organising 
knowledge  and  a  strategy  for  applying  that  knowledge.  Ex¬ 
ample*  of  problem  solving  modei*  include  forward  reasoning 
models,  backward  reasoning  modcr-,  event  driven  models, 
model  driven  model*,  etc.  In  a  forward  reasoning  model, 
the  Inference  step*  are  applied  from  an  initial  state  toward  a 
goal.  In  a  backward  reasoning  model,  problem  solving  begins 
by  reasoning  backward  from  a  goal  to  be  achieve*!  toward  an 
Initial  state. 

The  blackboard  model  (NiiSCb.NiiSCaJ,  which  wa*  devel¬ 
oped  in  the  1970'*  ami  ha*  undergone  very  few  changes  in 
the  last  ten  years,  uses  an  opportunistic  reasoning  mode!.  In 
an  opportunistic  reasoning  mode),  pieces  of  knowledge  are 
applied  either  backward  or  forward  at  the  most  appor/imc 
time.  Thi*  model  wa*  first  abstracted  from  the  Hearsay* 
II  sjieech  understanding  system  (NiiS2)  and  applied  to  the 
design  and  implementation  of  the  HASP  system  for  ocean 
surveillance  [KHHI.IISO].  Many  application  programs  have 
subsequently  been  implemented  (usually  in  l.isp)  using  the 
blackboard  model.  These  include  system*  for  interpreting 
electron-density  map*,  planning  errands,  understanding  mil¬ 
itary  signal*,  and  understanding  images. 

The  basic  blackboard  model  is  usually  described  as  con¬ 
sisting  of  three  major  components  •  the  knowledge  sources, 
the  blackboard  data  structure,  and  the  control  -  as  shown  in 
the  figure  on  the  following  page. 


*Tlii«  research  is  sponsored  Ly  the  Air  Force  Office  of  Scientific 
Heseardi. 
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—  data  flow) 


The  domain  knavhJge  *a*na  arc  partition*  for  med  from 
the  total  domain  knowledge  that  can  he  used  to  solve  the 
problem.  These  knowledge  turret  aro  logically  independent 
and  kept  serrate.  The  domain  tfecHeerv/  Join  slm/mr  is 
*  global  data  base  that  holds  the  problem  solving  state  data. 
The  solution  spaee  is  organised  into  one  or  more  application 
dependent  hierarchies.  Information  at  each  level  of  the  hi* 
erarthy  rrptexent*  partial  solution*  and  is  associated  with 
a  unique  vocabulary  that  describe*  the  information.  The 
knowledge  source*  produce  change*  to  the  blackboard  that 
lead  incrementally  to  a  solution  to  a  problem.  Common!* 
cation  and  interaction  among  knowledge  source*  take  place 
solely  through  the  blackboard.  There  is  no  predetermined 
(low  of  contra/.  The  knowledge  source*  respond  opportunis. 
tically  to  change*  in  the  blackboard.  The  knowledge  sources 
transform  information  on  one  level  of  the  hierarchy  into  in* 
formation  on  the  same  or  other  levels  using  algorithmic  pro* 
ccdure*  or  heuristic  rule*  that  generate  actual  or  hypothet¬ 
ical  transformations.  Which  knowledge  source  to  apply  Is 
determined  dynamically,  one  step  at  a  time,  resulting  in  the 
incremental  generation  of  partial  solutions.  The  choice  of 
a  knowledge  source  i*  based  on  the  solution  state  and  on 
the  existence  of  knowledge  source*  capable  of  Improving  the 
current  slate  of  the  solution. 

There  are  at  least  two  different  approaches  to  handling 
the  control.  The  first  has  control  residing  in  a  set  of  proce¬ 
dure*  wideli  monitor  the  changes  on  the  domain  blackboard 
and  trigger  appropriate  knowledge  sources  to  improve  the  so¬ 
lution  state.  In  the  second  approach,  control  is  achieved  by 
placing  the  strategy  on  a  control  blackboard.  The  decision 
then  as  to  vshat  to  do  next  is  made  by  control  knowledge 
sources  using  the  control  blackboard  where  data  describing 
the  stale  of  the  current  strategy  exists.  Strategies  can  be  en¬ 
abled  on  the  control  blackboard  to  reflect  the  current  state 
of  the  problem  solution.  This  second  approach  is  referred  to 
as  a  blackboard  control  architecture  [IIRS5]. 


The  blackboard  architecture  approach  improve*  on  tra¬ 
ditional  expert  systems  for  solving  ill-structured  problems  in 
the  following  wav*.  First,  the  blackboard  approach  require* 
no  a  priori  determined  reasoning  path.  Ikcause  ill-siruetuted 
problems  often  do  not  have  a  predetermined  decision  path 
to  a  solution,  the  selection  of  what  to  do  next  must  be  made 
while  the  problem  Is  being  solved.  The  capability  to  do  this 
is  provided  in  blackboard  systems  by  the  incremental  and 
©ppoitunislie  problem  solving  approach.  Second,  vague  in¬ 
formation  and  knowledge,  which  characterise  ill-structured 
problems,  need  to  be  made  concrete  In  the  process  of  finding 
a  solution  to  the  problem.  Tins  blackboard  n»odcl  is  an  excel¬ 
lent  tool  foe  tlds  knowledge  engineering  activity.  During  the 
initial  Interactions  with  an  expert,  a  knowledge  engineer  trie* 
to  find  an  appropriate  conceptual  model  for  the  task  while 
trying  to  understand  the  domain  and  the  nature  of  the  task. 
The  blackboard  approach  aids  in  the  problem  formulation 
because  it  provides  some  organisational  principles  that  are 
both  powerful  and  flexible.  The  blackboard  approach  is  also 
an  excellent  tool  for  exploratory  programming,  a  useful  tech¬ 
nique  for  developing  solutions  to  complex  and  ill-structured 
problems. 

Although  blackboard  systems  arc  useful  for  many  com¬ 
plex,  ill-structured  problems,  they  arc  generally  exjiensive 
to  build  and  to  use.  Therefore,  the  blackboard  approach 
should  not  be  used  when  lower  cost  methods  are  sufficient. 
A  problem  which  exhibit*  some  combination  of  the  follow. 
Ing  characteristic*  Is  a  good  candidate  for  the  blackboard 
approach: 

1.  a  large  solution  space 

2.  noisy  and  unreliable  information 

3.  »  variety  of  input  data  and  a  need  to  integrate  diverse 
information 

•I.  the  need  for  many  independent  or  semi-independent 
piece*  of  knowledge  to  cooperate  in  forming  a  solution 

5.  the  need  to  use  multiple  reasoning  methods  or  line*  of 
reasoning 

0.  the  need  for  an  evolutionary  solution 

A  proposed  application  should  he  carefully  analysed  be¬ 
fore  a  decision  to  implement  a  blackboard  system  is  made. 

3  Application  of  BB  Systems 

The  following  sections  describe  the  domain  analysis,  func¬ 
tional  requirements,  design,  and  implementation  of  the  pro¬ 
totype  system  for  a  classic  defense  problem. 
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3.1  Domain  Analysis 

Function*  of  a  classic  defense  system  include  iensing  of  the 
environment;  interpretation  of  conflicting,  incomplete  or  cor* 
rnpted  seniory  data;  integration  of  seniory  data;  overall  lit* 
nation  assessment;  planning  and  real-time  decisions  for  mil* 
lion  and  mrvival  achievement;  and  control  of  wcapo  system 
function*.  Thcie  activities,  wHM*  sre  currently  performed 
hy  the  crew,  would  ideally  Ire  provided  hy  a  ground  and/or 
onboard  computer  system.  The  system  would  l>e  able  to 
function  in  an  environment  containing  vail  amount*  of  raw 
data  where  the  data  may  lie  unintentionally  corrupted  via 
natural  phenomena  or  intentionally  corrupted  via  friendly  or 
enemy  jamming  ami  decqitiou  minion*. 

Electronic  warfare  (BW)  preceding  ipans  many  differ* 
eot  discipline*  (panSw  radio  frequency  (HF)  and  infrared 
(lit)  senior  interpretation,  active  HF  and  III  counteruwa* 
lure*  technique*,  etc.)  where  the  leuior*  ojierate  in  different 
environment*  with  different  requirement*  for  information  ex¬ 
traction,  interpretation  anti  reaction.  The  BW  »y*tem  must 
rcipond  to  a  deme  and  dynamic  environment.  A  priori  in* 
formatimi  i*  used  to  distinguiili  threat*  to  the  aircraft  front 
non-threat*  and  alio  contribute*  to  the  system  reipouic  ami 
resource  allocation  strategy.  A  priori  information  often  doe* 
not  represent  the  true  state  of  the  environment  because  of  cn- 
viromttenl  noise,  intentional  deceptive  emi**ion*,  jamming, 
etc. 

From  thi*  description  it  i*  easy  to  *ec  that  BW  exhibits 
several  of  the*  criteria  that  make  a  good  candidate  for  a  black¬ 
board  *y*tcm.  it  ha*  a  large  solution  space  that  include* 
knowledge  concerning  static  threat*,  limited  resource*,  pas¬ 
sive  sensors,  terrain  data,  platform  data,  active  countermea¬ 
sures,  goal*  to  be  accomplished,  etc.  Some  of  the  data  is 
noisy  and  unreliable.  There  i*  a  variety  of  input  data  and 
a  need  to  integrate  diverse  information.  There  i*  also  the 
need  for  many  independent  piece*  of  knowledge  to  cooperate 
in  forming  a  solution.  The  different  type*  of  knowledge  re¬ 
quire  different  vocabularies  and  different  line*  of  reasoning. 
The  solution  evolve*  a*  new  pieces  of  information  arc  sensed, 
input  and  derived  from  existing  data. 

One  BW  defense  problem  is  the  monitoring  of  a  hostile 
environment  by  a  moving  platform  for  the  purjmsc  of  deter¬ 
mining  the  platform's  best  path  through  the  environment. 
Emissions  are  detected  and  locations  ami  types  of  emitters 
are  determinal.  A  map  is  produced  which  represents  a  snap¬ 
shot  of  the  current  tr  ledge  alwul  the  environment.  This 
map  can  then  he  used  as  input  to  a  program  that  will  deter¬ 
mine  the  best  path  for  the  platform  through  this  environment 
|DDI.S$].  This  monitoring  problem  was  chosen  for  the  pro¬ 
totype  of  the  blackboard  control  system  in  Ada.  The  domain 
blackboard  will  contain  the  current  situation  board  with  re- 
spa:!  to  the  environment  while  the  control  blackboard  will 
contain  data  that  indicates  strategies  and  reasonings  to  he 
employed. 


3.2  Functional  Requirements 

The  functional  requirement*  for  the  prototype  include: 

1.  Process  balehc*  of  input  data  at  regular  interval*  of 
•I  time  units.  Input  data  can  be  cither  signal  data  or 
intelligence  reports.  Signal  data  consist*  of  three  emit¬ 
ter  characteristic*  *  frequency,  pulse  width  and  pulse 
rc|»ctitlon  frequency;  a  location  represented  by  a  posi¬ 
tion  on  a  grid;  and  a  signal  detection  lime.  Intelligence 
rc|*ort  data,  which  i*  for  threat*  only,  consist*  of  the 
location  and  sighting  report  time. 

2.  Determine  type  of  emitter  from  characteristic*  of  each 
set  of  signal  data. 

3.  identify  each  emitter  a*  threat  or  nonthreat  based  on 
the  capabilities  of  the  emitter  t/pe. 

-t.  Post  to  llm  current  situation  board  (CSD)  the  loca¬ 
tions  of  known  threat*  and  nonthreals  and  the  time  of 
sighting. 

5.  Eliminate  duplicate  sightings  hut  keep  history  infor¬ 
mation  for  each  location. 

C.  Keep  a  list  of  known  friendly  location*  to  determine 
whether  any  emitter  identified  a*  a  threat  i*  a  known 
friend. 

7.  Output  C$1)  at  regular  interval*  of  10  lime  unit*,  in¬ 
cluding  location  of  sighting,  threat  or  nonthreat,  his¬ 
tory  information,  and  confidence. 

S.  Output  SOS  message  immediately  when  possible  threat 
i*  detected. 

3.3  Design 

Two  different  design  methods  were  considered  for  the  system 
-  object  oriental  ami  functional.  The  choice  of  functional  de¬ 
sign  was  based  on  the  fact  that  blackboard  systems  and  the 
blackboard  control  architecture  have  been  descrihal  func¬ 
tionally  (IlHSOj.  As  the  system  is  decomposed,  the  functional 
design  approach  identifies  major  task*  to  he  performal.  Sub¬ 
program*  (program  units)  become  the  building  block*  of  a 
functional  design.  The  system  is  described  in  terms  of  the 
functions  that  process  the  data.  Functions  receive  input, 
transform  input,  and  produce  output.  The  functional  re¬ 
quirements  define  what  needs  to  he  done.  The  functional 
design  includes  the  requirements  as  well  as  the  data  flow. 
Pictured  below  are  the  various  levels  of  a  functional  design. 
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Al  the  highest  level, a  block  diagram  of  the  system  show* 
ing  inputs  and  outputs  would  look  like  this: 


clock 


signals — 


intelligence 
reports 


CSB  display 


emergency 

message 


The  major  function  of  the  monitoring  system  can  then 
be  broken  down  into  a  set  of  functions,  each  with  inputs  am! 
outputs. 
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3.4  Implementation 

The  blackboard  control  architecture  model  defines  two  black- 
Iwards,  one  for  the  domain  and  one  for  control.  A  set  of  data 
structures  and  a  set  of  knowledge  sources  arc  associated  with 
each  blackboard.  The  data  structure  for  each  blackboard  has 
Us  own  hierarchy.  Each  of  these  components  is  defined  below 
for  the  monitoring  problem. 

3.4.1  Domain  Blackboard 

The  hierarchy  for  the  domain  blackboard  contains  three  lev- 
els  of  abstraction:  signals,  emitters  and  sites.  The  domain 
knowledge  sources  are  listed  below; 

•  KSO.  Initialises  table  of  locations  of  known  friends  on 
domain  blackboard. 

•  KSl.  Heads  input  data,  creates  signal  node  on  signal 
level  of  domain  blackboard  or  creates  expectation  on 
site  level  of  domain  blackboard. 

•  KS2.  Generates  emitter  node  on  emitter  level  of  do¬ 
main  blackboard  based  on  characteristics  of  signal  node. 

•  KS3.  Generates  site  node  on  site  level  of  domain 
blackboard  based  on  characteristics  of  emitter  node 
and  other  information  on  domain  blackboard. 

•  KS5.  Handles  duplicate  emitter  nodes  on  emitter  level 
of  domain  blackboard,  updating  history  information. 

•  KSO.  Initiates  termination  of  system. 

•  KS7,  Prints  SOS  message  when  possible  threat  is 
sighted. 

•  KS8.  Outputs  CSB  and  associated  information. 


Execution  of  the  knowledge  source'  reflects  changes  in  the 
environment.  Both  forward  and  backward  reasoning  arc  used 
on  the  domain  blackboard.  Forward  reasoning  takes  signal 
input  data,  creates  emitter  ty|>es  from  the  signal  data,  am! 
generates  threat  or  nonthreat  sites  from  the  emitter  types. 
Backward  or  model  driven  reasoning  occurs  when  intelligence 
reports  indicate  a  threat  at  a  specific  location  al  a  specific 
time.  The  site  can  then  be  verified  based  on  the  intelligence 
report.  Discrepancies  at  this  level  result  from  noisy  or  unre¬ 
liable  data. 

3.4.2  Control  Blackboard 

The  control  blackboard  contains  three  levels  of  abstraction 
that  define  the  strategy  used  for  handling  events  that  occur 
in  the  system.  These  levels  are  policy,  tactic  and  step.  Policy, 
located  on  the  highest  level,  determines  which  blackboard 
is  dTected  -  domain  or  control.  Tactic,  on  the  next  level, 
specifics  the  category  of  event  to  process.  The  lowest  level 
of  abstraction,  step,  differentiates  between  the  two  low  level 
event  types. 
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The  control  knowledge  sources  toggle  between  possible 
values  on  each  level  of  abstraction  to  implement  the  chosen 
strategy. 

»  KSJO.  Initialises  the  system  with  problem  description 
from  user. 

•  KSll.  Initialises  control  blacklmard  by  setting  up  pol¬ 
icy.  tactic  and  step  level  for  |>oliey  being  used. 

•  KSU.  Generates  event  to  change  jsolicy  if  policy  is 
not  “control". 

•  KS 13.  Toggles  tactic  setting. 

•  KS 14.  Toggles  step  setting. 

•  KS20.  Toggles  policy  selling. 

Three  additional  domain-independent  procedures  •  up¬ 
date  trigger  list,  choose  KSAR,  and  execute  KSAR- 
drive  an  iterative  control  strategy  that  operates  around  three 
event  lists  -  action,  trigger  and  invocablc.  Upstate  trigger 
list  moves  KSAIts  from  the  action  list  to  the  trigger  list. 
Choose  KSAR  matches  conditions  of  control  ami  the  envi¬ 
ronment  with  the  KSAR  and  moves  the  KSAR  to  the  invoca* 
ble  list  if  the  conditions  arc  met.  Execute  KSAR  executes 
the  knowledge  source  of  the  first  KSAR  on  the  invocablc  list. 

3.4.3  Operation 

Updating  the  domain  blackboard  creates  events  that  reflect 
the  updated  environment.  These  events  are  recorded  in 
knowledge  source  activation  records  (KSA its).  A  KSAR  con¬ 
tains  information  on  the  triggering  cycle,  triggering  event, 
precondition  values,  condition  values,  trigger  weight,  knowl¬ 
edge  source  importance,  event  type,  rating  and  priority.  The 
KSAR  is  initially  placed  on  the  action  event  list.  The  action 
event  list  contains  all  KSAIts  generated  by  the  previous  cy¬ 
cle’s  execution.  As  KSA  Its  on  the  action  event  list  are  moved 
to  the  trigger  event  list,  the  events  arc  given  a  rating  based 
on  the  current  state  of  the  environment  and  the  importance 
of  the  associated  knowledge  source.  The  KSAIts  arc  placed 
on  the  trigger  event  list  in  descending  order  by  rating  points. 
KSAIts  are  moved  to  the  invocable  event  list  based  on  the 
current  control  strategy.  The  knowledge  source  of  the  first 
KSAR  on  the  invocablc  list  is  executed.  If  no  knowledge 
source  is  triggered  on  a  particular  cycle,  an  event  is  created 
that  will  enable  a  change  in  policy,  tactic  or  step  level  on  the 
control  blackboard. 

The  action,  trigger  and  invocablc  event  lists  contain  both 
domain  and  control  events.  The  policy,  tactic  and  step  set¬ 
tings  determine  which  KSARs  get  moved  to  the  invocablc 
list.  Only  one  event  activates  a  knowledge  source  (KS)  each 
cycle  -  the  event  that  is  first  on  the  invocablc  list.  The  execu¬ 
tion  of  a  knowledge  source  on  a  cycle  generates  new  KSARs 
on  the  action  list.  A  general  diagram  of  the  system  is  shown 
below. 


4  Use  of  Ada 

The  monitoring  system  was  developed  in  V»x  Ada  on  a  Vax 
II/7S0  running  the  VMS  operating  system.  The  use  of  Ada 
for  this  prototype  presenter!  no  major  problems.  The  re¬ 
sulting  system  has  the  structure  shown  below.  (The  arrows 
indicate  required  visibility.) 


Several  of  Ada’s  features  greatly  facilitated  the  imple¬ 
mentation.  The  package  concept  facilitates  data  encapsu¬ 
lation,  modularity,  and  locality.  Operations  on  a  particular 
object,  for  example  an  event,  are  contained  in  a  package  with 
the  implementation  details  hidden  from  users  of  the  pack¬ 
age.  Changes  in  the  implementation  will  not  effect  the  con¬ 
trol  structure  or  the  object’s  interaction  with  other  objects. 
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The  modularity  feature  of  the  package  encourages  reusabil¬ 
ity  as  basic  o|)cratioux  can  he  reused  and  not  reprogrammed. 
Pcckages  were  used  to  contain: 

•  blackboards  with  associates!  procedures  (data  and  util* 
ities  package) 

•  procedures  to  execute  cycle  for  control  (control) 

•  knowledge  sources  (KSs) 

The  data  and  utilities  package  contains  all  global  struc< 
lures  and  utilities.  The  control  and  domain  blackboards  are 
slelinesl  in  this  package  along  with  proceslures  that  delete 
information  from  the  domain  blacklsoard  as  well  as  create, 
add  and  delete  nodes  from  the  action,  trigger,  ami  invocable 
event  lists.  Much  of  this  package  is  reusable  since  it  ma:tip< 
ulates  the  structures  for  a  blackboard  control  architecture. 

Rath  knowledge  sour>  e  is  contained  in  a  separate  pack¬ 
age.  New  knowledge  sources  can  be  added  ami  existing  ones 
changed  without  recompiling  the  entire  system.  (Instead  of 
packages,  knowledge  sources  could  Ik?  contained  in  separately 
compilable  procedure  modules.)  Keeping  these  knowledge 
sources  separate  wilt  also  facilitate  the  introduction  of  con¬ 
currency  into  the  system  using  the  tasking  feature.  More 
that  one  .knowledge  source  could  then  be  executed  in  a  cy¬ 
cle. 

Other  Ada  features  were  also  useful  in  the  development 
of  this  system.  Variant  records  were  used  to  represent  black- 
Iward  nodes  since  the  nodes  on  the  different  levels  of  the  do¬ 
main  blackboard  contained  different  information  field*.  Us¬ 
ing  variant  records  made  it  |>ossil»!e  to  manipulate  the  node* 
on  all  levels  with  the  same  procedures. 

The  one  disadvantage  that  we  encountered  resulted  from 
changes  in  the  structure  or  information  that  was  on  otic  of  the 
blackboard*.  Any  changes  in  the  data  am!  utilities  package 
made  it  necessary  to  recompile  all  other  units.  Changing  the 
tables  from  static  to  dynamic  ami  initializing  them  from  files 
would  eliminate  many  of  the  changes  that  were  required. 

5  Conclusions 

A  prototype  monitoring  system  based  on  the  blackboard  con¬ 
trol  model  of  problem  solving  was  successfully  implemented 
in  Ada.  Blackboard  systems  exhibit  several  characteristics 
that  parallel  feature?  of  Ada.  The  independent  knowledge 
sources  can  be  developed  ns  program  units.  Packages  can 
encapsulate  operations  on  specific  types  of  data.  The  task¬ 
ing  mechanism  can  provide  the  dynamic  property  required 
by  the  control  mechanism.  The  use  of  Ada  tasks  will  al¬ 
low  a  natural  movement  to  multiprocessor  systems.  These 
features,  along  with  the  capability  to  incrementally  build  a 
solution,  make  Ada  a  good  choice  for  a  blackboard  system. 

The  incorporation  of  A I  techniques  into  solutions  of  real 
world  problems  has  been  hampered  by  the  use  of  speciality 
languages  for  their  implementation.  Ada  provides  the  vehicle 
for  moving  these  techniques  out  of  the  research  laboratories. 
Successful  integration  of  artificial  intelligence  techniques  into 
Ada  will  create  adaptable  software  packages  that  arc  highly 
suitable  for  solving  real  world  problems. 


References 

(AdkSG)  M.  Adkins.  Flexible  data  and  control  structures 
in  ada.  In  2nd  Annua/  Confertn cc  on  Artificial 
Intelligence  and  Ada,  1DSG. 

{BraSGj  I).  Ilraucr.  Ada  and  knowledge-based  systems: 

A  prototype  combining  the  best  of  both  worlds. 
In  First  International  Conference  on  Ada  Pro¬ 
gramming  Language  Application s  for  the  NASA 
.Space  Station,  1886. 

(1)1)1,88)  V.  Dobbs,  II.  Davis,  and  C.  hizza.  An  ap¬ 
plication  of  heuristic  search  techniques  to  the 
problem  of  flight  path  generation  in  a  military 
hostile  environment.  In  1st  International  Com 
/erenee  on  Industrial  and  Engineering  Applica¬ 
tions  of  Artificial  Intelligence  and  Expert  Sys¬ 
tem*,  10SS. 

(DohSS)  V.  Dobbs.  Reusable  ada  module*  for  Artificial 
intelligence  applications.  In  6th  National  Con¬ 
ference  on  Ada  Technology,  198$. 

(RIllUAtSO)  I#.  Krman,  F.  Itaycs-ltoth,  V.  I.csser,  and 
1).  Itcddy.  The  hcarsay-ii  speech  understanding 
system:  Integrating  knowledge  to  resolve  uncer¬ 
tainty.  ACM  Computing  Survey*,  12:213-251, 
June  10S0. 

(FraSG)  M.  Frank.  Using  ada  to  implement  the  op¬ 
eration*  management  system  as  a  community 
of  exerts.  In  First  International  Conference 
on  Ada  Programming  Language  Application*  for 
the  NASA  Space  Station,  19SG. 

(IIRS5)  B.  Ilnyes-Roth.  A  blackboard  architecture 
for  control.  Artificial  Intelligence,  20:251-321, 
19S5. 

(JI/4S7)  A.  Jaworski,  I).  LaVallce,  and  !).  Zoch.  A  lisp- 
ada  connection  for  expert  system  development. 
In  3rd  Annual  Conference  on  Artificial  Intelli¬ 
gence  and  Ada,  19S7. 

(l.aVSG)  I).  baVallee.  An  ada  inference  engine  for  ex¬ 
pert  systems.  In  First  International  Conference 
on  Ada  Programming  iMnguagc  Applications  for 
the  NASA.  Space  Station,  19SG. 

[NiiS2]  II. P.  Nii.  Signal-to-syinbol  transformation: 

llasp/siap  case  study.  A I  Magazine,  Spring 
19S2. 

(NiiSGa)  II. P.  Nii.  Blackboard  application  systems  and 

a  knowledge  engineering  perspective.  Al  Mag¬ 
azine,  7(4),  August  19SG. 

(NiiSGb)  H.P.  Nii.  The  blackboard  model  of  problem 
solving  and  the  evolution  of  blackboard  archi¬ 
tectures.  Al  Magazine,  7(3),  Summer  1980. 


42  7th  Annual  National  Conference  on  Ada  Technology  1989 


(RKWS3)  I/.  Rcckcr,  J.  Krcutcr,  and  K.  Wauehopc.  Ar¬ 
tificial  intelligence  in  a<ia:  Pattern-directed 
processing.  Technical  Report  AFHRI.-TR-12, 
APIIRU  May  1955. 

(SPA5GJ  I).  Scheldt,  l).  Preston,  ami  M.  Armstrong. 

Implementing  semantic  network*  in  aria.  In 
2nd  Annual  Conference  on  Artificial  Intelli¬ 
gence  «n« l  Ado,  1950. 


Pamela  Cook  received  the  M.S.  degree  in  computer  sci¬ 
ence  from  the  University  of  Dayton  in  1979  and  has  been 
pursuing  a  Plt.D.  in  computer  science  at  Wright  State  Uni¬ 
versity.  She  has  held  computer  scientist  position*  with  l  ord 
Motor  Credit  Company,  General  Motors,  and  Federal-Mogul. 


Verlynda  Dobbs  received  her  Pli.D.  in  computer  sci¬ 
ence  from  The  Ohio  State  University  in  19S5.  Her  research 
interests  are  in  the  areas  of  software  engineering,  artificial 
intelligence,  and  Ada  for  artificial  intelligence.  Dr.  Dobbs 
is  currently  on  the  faculty  of  the  Department  of  Computer 
Science  and  Engineering  at  Wright  State  University,  Dayton, 
Ohio  *15135. 


7th  Annual  National  Conference  on  Ada  Technology  1989  43 


The  AS7TSC-M  Redesign  Effort  - 
An  Experience  in  Software  Engineering  with  Ada 


E.  Peter  Gunderson 

David  A.  Vaughn 

Cordon  E.  Bostic  11 

Teles  Federal  Systora 

Teles  Federal  Systems 

Teloa  Federal  Sysurw 

ABSTRACT 

This  paper  examine*  the  first 
attempt  of  a  snail  development  tean 
with  no  experience  ir.  Ada  or  Object- 
Oriented  Design,  to  design  a  real¬ 
time  system  utilising  Ada.  The 
developed  software  controls  radio 
communications  equipment.  It  will 
replace  the  existing  software  used  to 
send  and  receive  digital  messages  and 
allocate  equipment  on  a  timed 
schedule.  The  success  of  this  devel¬ 
opment  proves  the  viability  of 
extending  the  useful  Hie  of  aging 
system*  by  replacing  software  and 
upgrading  processors  at  a  much  lower 
cost  than  developing  a  new  system. 
This  paper  relates  to  both  new  user* 
of  Ada,  who  will  possibly  encounter 
many  of  the  same  problems;  and  to  Che 
experienced  software  designer  who  nay 
avoid  similar  problems. 


INTRODUCTION 

The  U.S.  Army  Communlcations- 
ElccCronlcs  Command  (CECOM)  Center 
for  Software  Engineering  (CSE),  Fort 
Monmouth,  NJ,  tasked  Telos  Federal 
System*  to  conduct  a  feasibility 
study  lnvol'.  g  the  redesign  and 
rehost  of  AN  SC-99  software.  The 
objectives  of  ibis  cask  were  to  per¬ 
form  the  following: 

a.  Provide  a  working  under¬ 
standing  of  Ada  as  it  applies  to 
equipment  control  and  real-time 
scheduling  functions 

b.  Provide  a  test  bed  model 
for  requirements  analysis  of  system 


interfaces,  especially  operator  key¬ 
board  entry  and  displays 

c*  Provide  hands-on  software 
engineering  training  using  Ada  to 
explore  timing  and  responsiveness, 
memory,  siting,  and  multi-tasking 
designs 

d.  Evaluate  program  support 
environment  cools  and  compilers 
through  operation  and  benchmarks 

e.  Prove  the  viability  of 
using  Ada  to  control  the  AN/TSC-99. 

I .0  THE  SYSTEM 

The  AN/TSC-99  is  a  computer  con¬ 
trolled,  High  Frequency  (HF)  Radio, 
Burse  Communications  System.  It  1* 
contained  in  two  shelters;  the 
Receiver  Croup  Subsystem  (RCS),  and 
the  Transmitter  Croup  Subsystem 
(TCS).  These  shelters  can  be  sepa¬ 
rated  by  up  to  five  miles.  The  RCS 
processor  controls  four  HF  trans¬ 
mitters,  five  receivers,  and  one 
satellite  transceiver.  Normally,  the 
system  is  controlled  by  the  RCS 
processor.  In  the  evont  of  RCS 
system  failure,  Che  TCS  can  operate 
at  reduced  capacity  in  the  off-line 
mode.  RCS  software  also  controls 
ocher  devices  such  as  paper-tape 
punches  and  readers.  Device  inter¬ 
faces  are  serial  using  RS-232  proto¬ 
col.  The  current  fielded  version  of 
the  AN/TSC-99  is  written  In  ROLM 
assembly  language  and  targeted  to  the 
military  computer  family  equipment, 
which  includes  the  ROLM  1602B  proc¬ 
essor,  ROLM  2150  I/O  chassis,  and  a 
DATARAM  disk  emulator.  The  system 
configuration  is  shown  in  Figure  J. 
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1 . 1  THE  SOFTWARE  PROBLEM 

The  AN/TSC-99  could  no  longer 
support  change*  In  operational 
requirement* ,  primarily  dun  to  a  lack 
of  -memory.  Developing  a  paging 
scheme  was  con*ldered  but  deemed 
unacceptable  because  of  the  cost  of 
development  and  the  expected  degrada¬ 
tion  In  performance.  Other  consid¬ 
eration*  supporting  a  redesign  effort 
Included  the  elimination  of  obsolete 
peripherals,  incorporation  of  modern 
communications  security  equipment, 
and  adaptation  of  software  to  dif¬ 
ferent  hardware  configurations. 

1 .2  THE  TARCET  PROCESSOR 

TELOS  intended  to  provide  a 
rapid  prototype  of  n  functionally 
equivalent  system  written  In  Ada  and 
capable  of  running  on  a  modern  high¬ 
speed  processor.  Zenith  Z248s  were 
chosen  as  both  host  and  target  proc¬ 
essors  for  the  prototype.  While 
there  were  drawbacks  to  this  configu¬ 
ration,  this  solution  was  chosen 
because  Z248s  were  already  In  inven¬ 
tory  and  we  wanted  to  keep  develop¬ 
ment  costs  to  a  minimum.  The  porta¬ 
bility  of  Ada  would  allow  porting  to 


another  processor  with  minimum  effort 
If  required.  Meridian's  8Q286  Ad t, 
compiler  was  selected  because  It 
could  run  on  a  standard  PC  and  was 
validated  by  the  Ada  Joint  Program 
Office  (AJPO).  The  hardware  con¬ 
figuration  of  the  prototype  Is  shown 
In  Figure  2. 

2.0  DES1CH  COALS 

We  entered  Into  this  Feasibility 
Study  with  three  separate  design 
objectives:  (1)  to  develop  software 
that  would  lend  itself  to  easy 
upgrade;  (2)  to  maintain  the  same 
basic  user  Interfaces,  using  an 
extension  of  the  existing  AH/TSC-99 
Users  Guide  as  a  functional  specifi¬ 
cation;  and  (3)  to  make  the  code 
portable  and  reusable  to  the  greatest 
extent  possible. 

3.0  PROJECT  ORGANIZATION 

The  project  was  organized  under 
a  System  Architect  who  performed  the 
duties  of  the  Chief  Programmer.  The 
working  organization  is  shown  in 
Figure  3.  Two  software  engineers 
worked  under  the  System  Architect, 
one  concentrating  In  peripheral 
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FIGURE  2.  AN/TSC-W  PROTOTYPE  CONFIGURATION  WITH  ACL  CARDS 


Interfaces  progranaed  In  asaeably 
language.  The  second  devoted  to  the 
overall  design  and  Integration  of  the 
Ada  prograas. 

3.1  PROJECT  DEVELOPMENT  PLAN 

Dcvclopaene  followed  the  planned 
schedule  highlights: 

a.  He  esefnated  one  year  would 
be  the  required  to  coaplece  the 
project  as  the  rcqulreaents  were 
clearly  understood,  target  equlpnont 
was  in  place  and,  with  the  exception 
of  the  new  coaputers,  fully  Inte¬ 
grated  . 

b.  Four  engineers  were  to  be 
dedicated  to  the  design  of  the  proof 
of  concept  prototype.  If  the 
prototype  proved  successful  the  staff 
would  be  expanded  to  six  engineers. 

c.  We  would  train  on  the  Job, 
teaching  ourselves  both  Ada  and 
Object-Oriented  Design  techniques. 


FIGURES.  TEAM  ORGANIZATION 
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3.2  FACILITIES  ASP  SUFFOkT  SOFTWARE 

One  office  was  to  be  used  as  a 
software  development  lab.  This 
office  would  contain  three  2248s  and 
one  printer.  A  separate  office  would 
be  used  as  a  test  facility.  It  would 
contain  two  2248s  and  three  MH  XTs . 
The  2248s  would  be  used  as  target 
processors  (one  RCS  and  one  TCS). 
The  XTs  were  to  be  used  to  emulate 
equipment  in  the  AK/T5C-99.  Test 
facility  layout  it  shown  in  Figure  4. 
Much  tine  was  spent  on  the  develop- 
aent  and  naintenanee  of  our  facili¬ 
ties.  Software  was  written  to 
eaulate  radio  interface  cards  and 
paper-tape  readers(  create  aessage 
data,  and  aonltor  data  lines.  Addi¬ 
tional  software  was  written  to  auto¬ 
mate  compiling  and  linking  of  Ada 
program.  C,  Assembly,  and  Ada  were 
used  in  writing  this  software.  In 
all,  26  support  programs  were  writ¬ 
ten.  The  development  spanned  four 
versions  of  the  Ada  compiler. 
Installing  and  recompiling  with  each 
new  release  was  tine  consuming  as 
complete  compatibility  between  ver¬ 
sions  was  not  always  maintained. 


3.3  COHKUSICATIOX 

Most  communication  within  the 
team  was  verbal.  Design  changes  were 
discussed  and  agreed  to  during  design 
reviews.  The  team  was  managed  by  a 
chief  programmer  who  coordinated  all 
activities  and  facilitated  direction 
and  control.  This  approach  was 
chosen  to  expedite  development. 
Documentation  was  kept  to  a  minimum 
although  skeletons  of  most 
00D-STD-2 1 67  required  documents  were 
generated,  including  a  software 
requirements  specification  and  top- 
level  design  document. 

3.4  CONFIGURATION  HANACF.HKNT/QUAUTY 

ASSURANCE 

Configuration  Management  (CM) 
was  applied  to  two  Ada  baselines,  one 
TCS  and  one  KCS.  Once  developed, 
each  was  controlled  independently. 
The  moving  baselines  were  continually 
maintained  and  completely  updated 
after  each  Integration  test*  PC- 
based  metrics  software  wag  used  to 
monitor  program  coding  techniques. 


FIGURE  4.  IN-HOUSE  SOFTWARE  TEST  ENVIRONMENT 
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3.5  1KTECRATI0X  ASP  TESTIXC 

Existing  AK/T5C-9?  test  proce¬ 
dures  were  used  for  system  level 

testing.  Unit-level  testing  was 
performed  by  developing  engineers. 
Integration  testing  provided  full 
string  transmission  of  messages 

through  the  system. 

4.0  APPROACH 

4.1  PERIPHERAL  COXTROL 

Knowing  the  limitations  of 
Implementing  a  real-time  system 
running  under  HS-00S,  our  first  con¬ 
sideration  was  how  to  handle  Inter¬ 
rupts  (ton  16  serial  ports.  We 
decided  to  use  distributed  proces¬ 
sing,  purchasing  off-the-shelf 

Advanced  Communication  Link  (ACL) 
boards  manufactured  by  Stargste 

Technology.  Each  ACL  contained  eight 
user-configurable  serial  ports. 
Hardware  Interrupts  were  handled  by 
sn  on-board  Intel  8088  mlcroproces- 
sor.  Infornatlon  was  passed  to  the 
2248s  through  a  32k  window  of  dual¬ 
port  memory.  Assembly  language 
routines  were  used  to  service  the  ACL 
board.  These  routines  updated  a 
service  table. 

4 . 2  SOFTWARE 

Ada-tasklng  was  used  to  monitor 
the  service  cable,  Instantiating 
other  casks  as  required.  The  exist¬ 
ing  system-level  specification  was 
used  to  determine  requirements  of  the 
software.  We  coded  a  few  func¬ 
tionally  equivalent  procedures  In  Ada 
In  an  attempt  to  got  soae  rough 
sizing  data.  We  estimated  the  Ada 
Implementation  would  be  about  two  to 
three  Claes  as  largo  as  the  existing 
Assembly  language  lapleaentat Ion . 

4.3  TIHIKC 

All  critical  timing  (l.e.,  hard¬ 
ware  Interrupts)  was  handled  by 
existing  aabedded  firmware,  80286 
assembly  language  routines  and  the 
ACL  boards.  Ada  casks  were  used 
where  tiding  was  less  crtcltal,  such 
as  allocating  equlpaenc  and 
scheduling  outgoing  aessage  traffic. 
Equlpnenc  allocation  began  five 
nlnutcs  prior  to  message  transnls- 
slon.  A  one  nlnutc  window  was 
allowed  for  transolsslon.  The  ser¬ 
vice  cable  used  to  activate  these 
tasks  was  monitored  once  every 
second . 


3.0  DESICX  IHFLEHF.XTATIOX 

We  decided  to  first  design  and 
prototype  a  skeleton  of  the  TCS  side 
of  the  system.  The  Idea  was  to  prove 
the  viability  of  our  concept.  This 
node!  would  simply  load,  schedule, 
and  transmit  a  digital  message  over 
HE  radio.  The  message  would  be 
captured  In  the  R65  using  existing 
software.  If  successful,  the 
paradigm  would  be  expanded. 

5.1  TOP  LEVEL 

A  onblnatlon  of  Structured 
Analysts  and  Design  and  Object- 
Oriented  Design  techniques  were  used. 
The  static  structure  of  the  system 
was  developed  and  Interpackage  depen¬ 
dencies  were  loosely  defined.  When¬ 
ever  possible  dependencies  were 
Incorporated  Into  the  package  bodies. 
This  was  done  to  reduce  compile  times 
ac  new  dependencies  were  identified. 
Oats  structures  were  written  for 
peripheral  Interfaces  and  displays. 

Rapid  prototyping  was  used  to 
develop  the  framework  of  the  system. 
The  top-level  design  was  revised. 
Writing  of  package  specifications  was 
begun . 

5.2  DETAILED  LEVEL 

The  paradigm  was  further 
expanded.  The  unit-level  Interfaces 
were  fully  defined.  Package  specifi¬ 
cations  were  completed.  At  this 
point,  we  found  the  top-level  design 
often  required  revision. 

5.3  CODINC 

After  testing  the  proof  of  con¬ 
cept  model,  Implementation  proceeded 
from  two  directions.  The  low-level 
(Assembly)  modules  were  cackled  by 
one  team.  The  high-level  (Ada)  pro¬ 
cedures  were  coded  top-down  by 
another.  Engineers  were  provided 
with  the  specification  for  each  pro¬ 
cedure.  The  procedure  was  then  coded 
and  tested  at  the  unit  level.  When 
testing  was  completed,  the  procedure 
was  Integrated  into  the  package.  As 
packages  were  completed,  Integration 
testing  was  done  ac  the  interpackoge 
level.  Emulation  software  was  writ¬ 
ten  for  several  devices,  In  order  to 
lessen  the  number  of  trips  required 
to  Tobyhanna  Army  Depot,  Tobyhanna, 
Pennsylvania,  where  c  complete 
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AN/TSC-99  u«i  bed  1*  located.  Full 
system  tattling  uai  accomplished  using 
the  system  at  Tobyhanna. 

6.0  ACCOMPLISHMENTS 

The  resulting  executable  systea 
Is  approxlaately  2.S  does  the  site 
of  the  old  systea.  Wc  still  have  a 
SOT  nenory  reserve  In  the  RCS  and  615 
In  the  TC5.  Source  code  Is  approxi- 
oately  28,000  lines.  The  old  systeo 
contained  approxlaately  204,000. 
Much  loproveoent  has  been  realised  In 
aalntalnablllty.  Systea  response  Is 
cooparable  to  the  old  systea.  We 
feel  ue  can  laprove  this  slightly 
under  the  current  operating  systea. 
A  aultl-tasklng  real-tlae  operating 
systea  uould  probably  provide  sub¬ 
stantial  laprovenenc.  About  402  of 
the  code  was  reused  between  the  T6S 
and  KGS  programs.  So  conclusions  can 
be  reached  as  to  portability  as  we 
have  not  siteapced  to  port  to  another 
processor.  Productivity  averaged 
approxlaately  28  lines  of  code  each 
day  per  engineer.  This  was  sffected 
negatively  by  the  long  learning  curve 
and  positively  by  the  high  reusa¬ 
bility  of  code  within  the  systea. 

7.°  LESSONS  LEARNED 

As  a  result  of  this  Feasibility 
Study,  w«  uould  like  to  suggest  the 
following: 

a.  Users  should  fully  under- 
scand  the  Design  Methodology  being 
used . 

Understanding  Object-Oriented 
Design  techniques  was  one  of  our  aost 
difficult  casks.  Few  books  on  che 
subject  were  available  and  many 
questions  went  unanswered.  Most  of 
our  knowledge  cane  froa  papers 
written  on  che  subject.  The  aechods 
used  generally  followed  structured 
analysis  and  design,  however,  Top- 
Level  Design  of  the  Ada  programs 
attempted  to  apply  che  Object- 
Oriented  Design  for  package  conatruc- 
tlon.  This  gave  ua  good  data  flows 
for  procedures  and  minimal  package 
specifications  dependencies,  but  very 
large  data  structures  as  well. 

b.  Use  rapid  prototyping  for 
evaluating  design  approaches  and 
requirements  analysis  but  scop  shore 
of  full  implementation. 


We  found  that  changes  to  the 
Top-Uvel  design  were  being  driven  by 
detail  Implementation.  The  problem 
was  caused,  In  part,  by  never  getting 
out  of  the  rapid  prototyping  mode.  If 
automated  design  tonls  had  been 
available,  this  would  have  been  less 
likely. 

c.  Follow  a  methodology  and 
enforce  coding  standards. 

While  our  source  listings  are 
easy  to  read,  their  format  varies 
throughout  the  system.  Using  metrics 
to  monitor  development  contributed  to 
the  maintainability  of  code,  and 
helped  us  to  Identify  code  that  was 
too  complex  or  lacking  In  comments. 
As  a  result,  procedures  were  kept 
simple  and  contained,  on  average,  402 
comments.  The  point  of  maintaina¬ 
bility  was  brought  home  by  observing 
how  quickly  new  members  assigned  to 
the  team  became  productive.  TF.LOt  has 
now  instituted  formal  methodology  for 
use  In  developing  systems  Implemented 
in  Ada. 

d.  Emphasise  reusability. 

Reusability  saved  tine  and 
effort.  Since  the  TCS  requirements 
were  essentially  a  subset  of  che  RCS 
functions,  much  ’reusability  cane 
naturally.  Handling  of  Incoming  and 
outgoing  messages  in  the  RCS  shared 
many  common  qualities,  which  allowed 
reusability  by  dealgn.  Having  spent 
more  time  on  identifying  reusable 
functions  could  have  eliminated 
duplicated  code. 

e.  Share  files/packages  during 
development . 

We  initially  believed  chat  we 
could  develop  codo  in  our  own  direc¬ 
tories  and  port  the  finished  product 
to  a  package  In  a  central  directory. 
Uc  had  hoped  that  che  use  of  a 
"separate"  clause  would  allow  this, 
but  the  compiler  failed  to  support 
this  feature  after  100  separate  pro¬ 
cedures  had  been  completed.  With  a 
staff  of  six  engineers,  this  proved 
to  be  an  inconvenience.  Had  che 
system  been  larger,  we  would  have 
developed  major  problems.  Proper 
utilization  of  Configuration  Manage¬ 
ment  during  development  stages  uould 
have  helped  to  avoid  die  headaches 
caused . 
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.  Select  a  nature  conpller. 

Our  conpller  was  the  cause  of 
nany  problems.  la  early  releases 
nany  features  414  out  work  correctly* 
As  the  coaptler  oatured  nest  problens 
were  corrected.  In  the  current 
release,  Version  2.2,  the  only  aajor 
deficiency  we've  found  Is  the  corrup¬ 
tion  of  heap  storage  when  using 
string  concatinatlon*  This  problen 
has  been  overcone  by  using  slices  to 
construct  strings* 

The  prohleas  we  encountered  are 
not  unique  to  Meridian*  Ada  Is  the 
nost  conplex  language  ever  developed 
and  all  Ada  conpllers  have  suffered 
the  sane  growing  pains*  In  fact, 
Meridians  eoapller  has  nany  valued 
features*  It  interfaces  easily  with 
asseably  and  C  code.  Several  support 
packages  such  as  the  DOS  envlronaent 
and  utilities  packages  are  clso 
available.  «e  feel  Meridian’s  eon- 
piler  represents  a  good  value  for  the 
noney . 
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Sumtmoi 

This  paper  present*  a  complete  methodology  for  the 
design  phase  of  a  large  real-rime  software  project.  It 
assume*  the  project  is  being  developed  under  DOD* 
STD-2I67A'  *sd  will  be  implcmemcd  in  Ada.  In  DOD- 
STD-2I67A  term*,  both  the  preliminary  design  and 
detailed  design  phase*  arc  covered.  Because  the 
methodology  presented  in  this  paper  incorporate*  idea* 
from  most  of  the  methodologies  currently  in  vogue,  it  i* 
called  the  Hybrid  Methodology  The  Hybrid 
Methodology  has  two  purposes:  to  provide  an  outline  of 
the  engineering  steps  required  by  a  team  of  software 
developer*  to  design  a  real-time  system,  and  to  relate 
the  engineering  process  to  the  Software  Design 
Document  (SDD)’  required  by  DOD-STD-2167A. 

tau&tuo&n 

There  ha*  been  much  written  on  software  engineering 
methodologies,  especially  with  the  advent  of  Ada, 
Several  are  specifically  geared  to  developing  software  in 
Ada"J.  Several  address  developing  real-time  systems"'’. 
Sotne  deal  with  the  transition  from  requirements 
definition  to  design".  Norte  tclatc  Use  design  process  to 
tlte  DOD-STD-2I67A  products  and  pluses.  In  fact, 
Donald  Fitesmith  gives  lectutes  on  Ada  project 
management'  telling  managers  tltat  Ada  and  DOD-STD- 
2I67A  do  nor  fit. 

The  Hybrid  Metltodology  provide*  an  approach  to 
developing  the  Software  Design  Document  as  a  natural 
by-product  of  the  engineering  process,  It  lakes 
advantage  of  tlte  expressiveness  of  Ada  to  present  tlte 
design  information  so  tltat  it  evolves  naturally  into  an 
implementation.  All  aspects  of  designing  software  for  a 
large  rcal-tinte  system  are  taken  into  account,  including 
early  design  of  tlte  implementation  framewotk  of  tlte 
system  (tlte  software  architecture  concepts),  support  of 
discrete  event  simulation  of  (lie  system,  and  traceability 
to  requirements. 

Design  Pluses 

Tlte  Hybrid  Metltodology  is  presented  in  two  pans: 
prcliminaiy  design  and  detailed  design.  Tlte  paper 
assumes  that  tlte  requirements  analysis  phase  has  been 
completed  and  that  tltere  is  a  Software  Requirements 
Specification  (SRS)"*,  and  a  system  data  flow  diagram. 


The  fiat  part  of  preliminary  design  provide*  traoeafedny 
to  the  SRS  and  transition*  from  a  requirement*  view  of 
the  system  to  an  implementation  view.  Both  the 
preliminary  design  and  detailed  design  phase*  ate 
subdivided  into  step*  which  relate  to  the  engineering 
process.  Each  step  culminate*  in  documenting  'he  design 
at  that  point  in  appropriate  Section*  of  the  Software 
Design  Document.  The  Software  Design  Document  U 
therefore  incrementally  developed  and  reviewed  a*  the 
cnginecting  l*  done  and  not  in  a  tush  shortly  before 
tklivery. 

The  Hybrid  Methodology  i*  presented  assuming  a 
system  consisting  of  a  single  Computer  Software 
Configuration  Item  (CSC!),  However,  It  Can  also  be 
applied  to  a  system  consisting  of  multiple  CSCls, 
Usually  the  panitioning  of  a. system  into  multiple  CSCI* 
take*  place  before  the  SRS*  ate  written.  The  CSCI*  ate 
usually  defined  on  functional  (and  possibly  hardware) 
boundaries.  The  Hybrid  Methodology  in  till*  case  would 
begin  by  writing  the  architecture  concept*  paper 
described  below  for  the  system  as  a  whole.  Section  3.1 
of  the  SDD  for  each  CSCI  would  iltcn  be  described  in 
terms  of  the  concept*  in  tlte  architecture  concept*  paper. 

Mcthodolorv  for  Preliminary.  Pcsitn 

Preliminary  design  consist*  of  four  step*.  Each  Step 
refute*  tlte  design  produced  at  tlte  previous  step. 
Product*  are  developed  which  serve  to  document  the 
complete  design  at  each  step  and  to  scree  as  a  vehicle 
for  infomtal  review.  In  addition,  some  of  the  product* 
Scree  as  engineering  wotkpapers  which  will  be 

developed  into  deliverable  document*.  Tlte  four  step* 
arc: 

1.  Identify  top-level  CSC* 

2.  Identify  sub-level  CSCs 

3.  Produce  formal  documentation  for  each  sub-level 

CSC 

4.  Describe  abstract  algoritlun  of  cadi  sub-level 

CSC 


Tlte  description  of  each  step  starts  with  an  overview  of 
tlte  step.  If  tltere  are  concepts  which  help  in 
understanding  tlte  products  to  be  developed  during  tlte 
step,  they  are  presented  following  tlte  overview.  Tlte 
products  of  tlte  step  are  then  described.  Finally  a  list  of 
hlivcrabics  or  sections  of  deliverables  which  are 
.'ompleted  by  this  step  is  provided. 
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5ltpJL-J<ki^J«vkvd.C.§<^, 

Top-level  CSC*  arc  the  major  functional  entities  of  the 
system,  They  ate  derived  by  analysing  the  system  level 
dataflow.  ft*  *  real-time  sysrern,  we  start*  ar  the 
external  interface*  ami  workx  in,  identifying  the  major 
IKKty<b(  done  w  hwdlc  each  Interface,  There  should 
he  no  more  than  3*7  top-level  CSC*  for 

under*  andabil  it  y. 

After  the  I0p*kvcl  CSC*  are  identified,  the  software 
architecture  framework  ©f  tl>c  system  U  designed.  Thi* 
will  he  documented  hi  a  Software  Architecture  Concepts 
paper  whkh  will  he  preserved  In  the  CSC1  Software 
Ikvclopment  File  (SOI  ). 

Before  individual  team*  can  begin  designing  their  top- 
level  CSC*,  they  rou*  underwand  how  their  piece  Hi* 
into  the  system  from  an  hnjdemcnration  point  of  view. 
Thin  require*  a  top-down  design  of  the  mechanism* 
which  tie  the  system  togetltcr.  These  mechanism*  can 
then  be  Implemented  In  such  a  way  at  to  isolate  the 
“applkaiion*"  front  the  underlying  Operating  system  :nd 
hardware.  Thbt  framework  aim  provide*  Ihc  top  tlown 
design  of  nKcltanism*  whkh  control  and  detect  errot*  in 
die  system.  Once  these  mechanism*  have  been 
engineered  on  a  system  level,  there  will  be  derived 
requirement*  levied  ott  iIk  software  (and  possibly 
hardware)  in  order  to  implement  tluwc  mechanism*. 

Software.  AKhiK«urc_Ii>rA<S.  The  software 
architecture  of  die  system  I*  described  for  two  area*. 
The  fir*  l*  Monitor  and  Control.  Concept*  must  he 
developed  top  dawn  for  how  the  system  i*  to  be 
controlled,  and  what  l<  to  Ik  monitored.  T)k  focu* 
sltould  be  on  Utinking  in  tenn*  of  keeping  die  operator 
infonned,  ant!  in  tenn*  of  uhat  die  OfKrator  mu* 
control.  '11k  Second  area  I*  System  Service*.  TIicSc 
service*  arc  used  by  iIk  "application*”  of  iIk  system  to 
communicate  with  each  oilier,  to  acce**  common  data, 
and  perform  function*  In  a  system-defined  way.  Ttic 
intent  is  to  hide  die  $|>ecifies  of  iIk  operating  system 
from  die  rest  of  die  software,  and  to  provide  a  common 
framework  for  die  software. 

Motiitpr.and.Comrol.  Monitor  and  Control  must 
take  a  system  view.  Concepts  must  be  dcvclojxd  which 
relate  liow  individual  com|>oncm$  of  the  software  work 
togedicr  to  jicrfonn  stanup,  sliutdown,  fault  detection 
and  recovery. 

a.  Stanup/startover/shutdown 

Concepts  must  be  developed  for  starting 
die  system,  restarting  in  ease  of  a  crash, 
and  shutting  down  die  system.  What 
applications  can  Ik  restarted?  What  state 
data  must  be  maintained?  What 
mechanisms  will  be  used  for  recovering 
data  before  die  system  restarts?  How  will 


the  system  be  terminated  gracefully?  Will 
function*  be  able  to  be  started/terminated 
individually?  Will  function*  require  entries 
whkh  can  be  Called  by  Monrte:  and 
Control  to  start  up  or  terminate? 

b.  Fault  detection/fccovety 

Wbat  fault*  must  the  system  detect?  From 
what  fault*  must  if  recovery?  What  arc 
the  mechanism*  by  whkh  the  fault*  will 
be  detected?  How  will  error*  be  reported 
to  the  operator?  What  action*  will  the 
operator  be  able  to  take  to  recover)*  from 
faults? 

C.  Miscellaneous 

What  arc  the  possible  configuration*  of 
the  system?  How  will  die  system  be 
reconfigured?  Will  the  system  tun  in 
degraded  modes?  How  will  this  work? 

Svstcttuutvkc*.  System  scrvkc*  arc  needed  to 
provide  common  way*  of  passing  message*,  accessing 
data,  logging,  and  performing  algorithm*  common  to 
Several  applkation*  of  die  system. 

a.  Message  passing 

Application  functional  entitle*  whkh  may 
be  implemented  on  different  proec*sor*, 
or  whkh  may  move  from  one  processor 
10  another  doc  to  a  reconfiguration,  or 
whkh  should  Ik  decoupled  for  flexibility 
in  configuring  the  system  will 
communicate  via  a  system  scrvkc.  They 
will  send  a  message  to  a  functional 
address.  They  will  receive  message*  by 
identifying  themselves  a*  a  particular 
functional  address.  TIk  list  of  functional 
addresses  must  be  establish!.  ’Hie 
mechanisms  for  routing  data  using  die 
functional  address  ronccpt  and  for 
reconfiguration  must  Ik  developed. 

b.  Database 

T)k  operational  need*  for  data  must  be 
determined.  This  includes  adaptation  data 
a*  well  a*  data  gciKraicd  during  operation 
of  die  system.  Wliere  die  data  will  reside, 
liow  it  will  be  distributed,  mechanisms  for 
maintaining  consistency  and  validity  of 
die  data  must  be  determined.  Mechanisms 
for  updating,  reading  die  data  must  be 
designed. 

c.  Logging 

Requirements  for  logging  data  must  Ik 
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determined.  What  data  should  he  logged, 
how  will  it  he  logged?  On  a  distributed 
system  one  must  deckle  if  logging  will  he 
done  on  one  processor  or  on  each 
processor,  etc.  Control  of  logging  must  he 
designed.  Will  categories  of  tlata  lie 
ettablctlAJisahlcd  for  logging?  What  are 
the  categories  for  this  system?  What  will 
the  mechanism  he  for  enahling/disabling 
the  data? 

d.  Utilities 

A  first  step  at  klentifying  common  s;  cm 
utilities  is  done  at  this  time.  .Slandanl  data 
ty|>cs  arc  kkntificd. 

Products  .for  Step.  1 .  11»c  following  products  will 
be  gcncratetl  during  Step  I: 

a.  Grouping  of  functions  in  tire  system  level 
datallow.  'litis  may  he  by  thawing  on  tire 
dataflow  or  by  a  list  of  top-level  CSCs 
and  live  processes  of  iltc  system  level 
dataflow  allocated  to  exit. 

b.  Requirements  allocation  matrix  front  SRS 
to  top-level  CSCs. 

c.  Data  item  allocation  matrix  assigning  data 
items  from  tlte  SRS  to  top-level  CSCs. 

d.  Software  Architecture  Concepts  paper 
describing  tlte  software  architecture 
framewotk  of  tlte  system. 


Deliverables.  SDD  entries  1.0,  3.1  and  3.1.2 
will  lie  written.  SDD  3.1.1  will  be  started.  11k  Software 
Architecture  Concepts  paper  and  derived  requirements 
will  be  kept  in  tlte  CSCI  SD!;  section  2,i2.  'iltc 
requirements  allocation  matrix  will  be  pan  of  SDD 
section  7.  Hie  data  item  allocation  matrix  will  be  part 
of  SDD  section  5. 

Slcp.Z-^Idcmify-SubjcvcLCSCs. 

Sub-level  CSCs  primarily  siiow  the  concurrency  required 
in  tlte  system.  Constraints  due  to  hardware  and  tlte 
environment  stan  to  play  a  pan  licre.  A  sub-level  CSC 
may  also  be  identified  to  package  services.  Tlte  data 
(low  diagrams  (DFDs)  from  tlte  functional  analysis 
phase  are  used  in  this  process  to  determine  functions 
and  entities  that  should  be  sub-level  CSCs.  Tlte  process 
of  transitioning  (lie  functional  analysis  into  a  design  is 
called  "recasting"  the  DFD.  Some  of  tlte  criteria  that 
determine  what  constitutes  a  sub-level  CSC  include: 

l.  Concurrency:  Must  the  processing  be  done  as  a 
separately  sciieduled  process?  This  is  usually 
required  to  handle  external  events  or  because 


processing  must  be  done  periodically. 

2.  Object  oriented  design:  Is  this  entity  an  object 
which  contains  state  tlata  aitd  provides  operations 
on  tlut  data?  Is  this  an  entity  which  Cannot  he 
accessed  simultaneously  by  concurrent  processes? 

3.  Hncapsulatktn  and  in  format  km  hiding:  Is  this  a 
service  which  will  be  used  to  make  applications 
independent  of  the  specific  operating  system  or 
off-the-shelf  software  being  used  In  tbc  system? 
Note  that  these  do  not  usually  show  up  on  a 
DFD  but  arc  tcqulred  to  Insulate  applications 
from  dependencies  on  hardware  or  particular 
operating  systems. 

Steps  to 

take  to  "recast"  the  DFD  from  the  requirements  analysis 
phase: 

a.  Show  handlers  for  external  hardware 
interfaces.  If  an  external  interface  Is  full- 
duplex  (sending  and  receiving  of  data  arc 
independent),  one  may  want  to  show  a 
separate  handler  for  each. 

n.  Make  data  stores  into  objects. 

C.  Raise  processes  from  lower  levels  of  the 
dataflow  if  they  arc  necessary  to 

understand  major  processing  required.  Iltc 
product  of  steps  a,b,c  is  called  a 
preliminary  entity  diagram. 

d.  Collapse  processes  Into  lades  by  working 
inward  from  iltc  external  interfaces: 

i.  Cart  processes  on  iltc  data  flow  be 
done  sequentially  because  there  is 
lime  to  do  it  before  tlte  next  input 
arrives? 

ii.  Should  a  data  store  become  iltc 
state  data  of  a  process  already  on 
tlte  data  flow? 

'flte  product  of  this  step  is  called  tlte  final 
entity  diagram. 


Products  for  Step  2.  Hie  following  products  are 
developed  as  part  of  Step  2: 

a.  The  final  entity  diagram  for  each  top- 
levif  CSC  showing  tlte  Ada  tasks.  The 
entity  diagram  may  also  show 
serviccs/utilities,  if  tltey  help  tell  tlte 
story. 
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b.  Description  of  environment  assumed.  This 
will  include  any  operating  system  services 
or  off-tltc-shclf  software  you  arc  assuming 
in  lire  design. 

c.  Outline  containing  cadi  top-level  CSC 

and  its  sub-level  CSCs.  litis  will  be  kcjX 

in  live  Software  Development  Folder 

(SDF).  For  cadi  sub-level  CSC: 

i.  List  of  functions  (lie  sub-level  CSC 
is  to  jterfontt.  Tills  sliould  l« 
traced  to  die  SKS,  and  10  (lie 
tlcrivcd  requirements  frotn  il*c 
Software  Architecture  Conccjns 
paper. 

ii.  Rationale  for  making  die  sub-level 

CSC  a  task  or  a  service. 

Hi.  SKS  data  items  ’’allocated''  to  this 
sub-level  CSC.  'Iliesc  sliould  relate 
directly  to  data  flows  on  die  Dl-Ds 
and  track  wlicrc  diese  data  flows 
arc  in  die  design. 

iv.  Sfiedal  processing:  initialization, 

recovery,  shutdown  ami  error 
handling  of  this  sub-level  CSC. 
limn-  handling  lias  two  aspects. 
One  Is  to  implement  die  fault 
detection  and  recovery  mechanisms 
described  in  the  Software 
Architecture  Concepts  document. 
Tlic  other  is  to  begin  designing  die 
Ada  exception  logic. 

v.  Interfaces:  This  will  show  which 

interfaces  will  be  by  Ada 
rendezvous  (and  lienee  sliow  up  as 
procedure  specifications)  and  which 
will  be  by  system  message  passing 
services  or  I/O  services. 

Pclivcrahlcs.  SOD  3.2.x  will  lie  written  for  each 
top-level  CSC.  Tlic  final  entity  diagram  will  be  included 
in  ibis  section.  SDD  3.1. 1  will  be  completed. 

Tlic  environment  description  and  outline  will  be  kept  in 
die  top-level  CSC  SDF  section  2.11.  As  design 
progresses  this  paper  may  not  be  maintained  since  it 
serves  as  the  precursor  to  information  kept  in 
deliverables. 

Step  3  -  Document  nuroose  of  cachsub-lcvcLCSC. 

Tlic  purpose  of  Step  3  is  to  formally  describe  each  sub¬ 
level  CSC  using  Ada  as  a  Program  Design  Language 
(PDL).  Much  of  the  infonnation  will  be  found  in  Ada 
conunentary.  Tlic  PDL  will  be  compilable  and  will 
establish  the  interfaces  to  each  sub-level  CSC. 


'LreUlfJkb-icvd^C^.  Tliere  arc  two  types 
of  sub-level  CSCs.  The  first  is  an  object.  The 
documentation  of  an  object  sub-level  CSC  will  include 
a  description  of  dial  object  in  terms  of  an  abstract 
definition  of  its  state  data,  and  a  description  of  its 
operations  on  that  abstract  definition  of  tlic  state  data. 

The  second  type  of  sub-level  CSC  is  a  process.  It  Is 
best  described  as  a  classical  (iit|nit,  processing,  output) 
entity.  Usually  die  I/O  Is  via  system  calls  ratlicr  than 
(iroccdutc  or  task  entry  calls.  Therefore,  it  caiuiot  be 
described  as  operations  on  an  object. 

A  sub-level  CSC  may  be  a  combination  of  die  two 
types.  It  may  liavc  sonic  processing  which  is  best 
described  in  terms  of  (iii|tu(,  processing,  output)  and  in 
addition,  encapsulate  some  state  data  u|ion  which  a  user 
can  operate  via  ptoecdurc  calls. 

Overview  on  objects.  Following  is  a  discussion 
about  objects  a#  viewed  during  preliminary  design: 

An  object  is  a  data  type  (or  a  collection  of  data) 
together  with  operations  on  dial  data.  Tliere  arc  two 
views  of  tlic  object:  tltc  conceptual  view  and  die 
implementation  view.  At  preliminary  design  we  arc 
concerned  with  tlic  conceptual  view.  At  detailed  design 
we  arc  concerned  with  die  implementation  view.  Tlic 
Conce|itual  view  is  a  description  of  the  object  as  viewed 
by  die  user  of  die  package.  It  must  provide  a  dear  and 
complete  description  of  die  object,  and  tlic  operations 
on  tlic  object.  Included  in  that  description  arc  any 
consistency  rules  which  help  describe  the  concept  of  die 
object  in  icmis  of  data  dependencies,  uniqueness  of 
elements,  etc.  Tlie  operations  arc  specified  as  procedures 
and/or  functions,  togcilicr  with  a  complete  description  of 
tlic  effect  of  die  operation  on  tlic  conceptual  view  of 
tlic  object. 

Conunon  conceptual  views  used  are  sets,  queues,  stacks, 
database  tallies.  Often  an  object  is  not  completely 
described  by  saying  it  is  a  set  or  a  queue,  etc.  Tliere 
are  usually  conditions  dial  must  be  maintained  to 
provide  consistency.  Tliesc  arc  eitlier  interrelationships 
or  limitations  placed  on  die  data.  This  infonnation  may 
affect  die  design  of  die  user  of  object.  We  will  call 
tliesc  conditions  consistency  rules.  For  example,  an 
address  book  is  a  set  of  (name,  address)  pairs.  A 
consistency  rule  for  tlic  address  book  object  may  be  that 
for  a  given  name,  there  is  only  one  unique  address. 
This  limits  die  use  a  user  may  make  of  that  address 
book  object.  For  example,  if  a  user  wanted  to  put  both 
a  home  address  and  a  work  address  for  each  name,  lie 
would  have  to  design  some  way  of  making  die  name 
unique  (possibly  by  appending  “.II",  ",WM,  respectively). 

Products  for  Step  3.  The  following  products  will 
be  developed  during  Step  3: 

a.  Tills  infonnation  will  be  documented  as 
Ada  specifications  and  accompanying  Ada 
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comnxntary,  complemented  by  icxi  in  the 
SDD. 


i.  For  entities  which  we  objects  tlx 

conceptual  view  of  the  data  will 
be  described  with  Ada  cot nn ternary 
in  the  package  prolog.  The 
operation*  on  tltc  data  will  be  Ada 
specification*  of  procedure*  and/or 
functions.  Parameters  of  tltc 

procedures  will  be  docuntented  in 
type  definition  package*,  using  the 
"THD"  type  definition*  package 
when  refinement  of  tltc  data  type 
can  be  postponed  until  detailed 
design.  The  effect  of  tltc 

operations  on  tltc  conceptual  data 
will  be  described  in  tltc 

procedure/function  prologs. 

ii.  For  entities  which  are  (input, 
processing,  output)  entities,  tltc 
conceptual  view  of  that  processing 
will  be  described  with  Asia 
conuitcntary  in  tltc  package  prolog. 

iii.  For  entities  which  are  a 
combination,  both  types  of 
conutKiitary  will  be  present  in  the 
package  prolog. 

b.  Tltc  data  dictionary  will  be  updated  with 
tltc  mapping  between  SRS  data  items  and 
tltcir  location  in  Ada  packages.  Note  that 
tltey  may  map  to  Ada  data  types,  Ada 
data  packages,  or  even  futtciions  or 
paranteters  of  procedures.  Some  may  even 
not  appear  in  tltc  design  if  two  processes 
we  combined  into  oik  Ada  procedure 

c.  Tltc  requirciiKiits  traceability  matrix  will 
be  updated  to  show  which  sub-level  CSCs 
implement  each  requirement  in  tltc  SRS. 

Deliverables.  SDD  3.2.x.y  will  Ik  written  for 
each  sub-level  CSC.  Tltc  preliminary  PDL  for  tlw  sub- 
level  CSC  will  be  included  in  this  section.  SDD  5.  and 
7.  will  be  updated  to  show  traceability  to  the  sub-level 
CSC. 


CSC- 

This  step  supports  development  of  die  hardware 
resource  allocation  information,  estimates  of  source  lines 
of  code  and  modeling  of  the  system  using  a  discrete 
event  simulator. 

Overview  of  abstract  algorithm.  Although  we 
concentrate  on  the  abstract  view  during  preliminary 


design,  we  must  make  sure  the  design  will  work.  We 
therefore  make  simplistic  assumption*  about  the 
implementation  of  each  package  so  that  a  worst  case 
scenario  can  Ik  modeled.  Modeling  can  Itelp  identify 
area*  of  the  software  Utat  must  be  carefully 
implemented.  Modeling  can  also  verify  decisions  about 
allocation  of  the  software  to  hardware,  and  will  help 
develop  the  resource  allocation  infomtation  for  the 
SDD.  TIk  abstract  algorithm  l*  oriented  towards  the 
processing  required  per  input  for  each  operation  of  tlx 
object,  or  for  a  typical  input  to  a  processing  entity. 

Product*  for  Sten  A.  ‘11k  following  products  are 
produced  during  Step  -I; 

a.  Describe  implcnxnlation  assumptions.  It 
L*  assumed  that  system  cngiitecring  ha* 
provided  modelers  with  frequency  of 
external  inputs. 

b.  Estimate  number  of  Ada  staicnKnts  per 
step  in  algorithm  for  each  operation  of 
tltc  package.  This  includes  expected 
number  of  times  through  each  loop.  This 
estimate  may  be  per  reference  if  step  is 
to  be  perfonned  by  calling  on  an 
operation  of  anotlter  sub-level  CSC.  Note 
that  tlKrc  may  be  a  "background"  task, 
not  specified  a*  an  ojKRiiion,  but 
necessary  to  implement  concept.  For 
example:  a  garbage  collection  task  which 
runs  periodically  to  delete  old  entries  in  a 
database. 

c.  Estimated  source  lines  of  code. 

d.  estimated  memory  requirements. 

Deliverables.  SDD  3.1.3  will  be  written.  TIk 
algorithms  and  sizing  estimates  will  be  kept  in  the  top- 
level  CSC  SDF. 


TIk  first  step  in  detailed  design  is  to  outline  (Ik  logic 
to  be  used  in  tlx  "select"  statenKnt  of  each  task.  11k 
concurrent  entities  identified  in  preliminary  design  are 
expanded  upon.  One  sub-level  CSC  in  preliminary 
design  may  turn  into  several  tasks  in  detailed  design. 
Tasks  may  be  introduced  for  functions  which  are 
performed  periodically,  or  to  queue  data  to  provide  a 
looser  coupling  than  tlx  Ada  rendezvous.  Decisions  as 
to  which  entities  are  callers  and  which  are  called  are 
reviewed.  This  requires  examining  the  entity  diagram 
for  tasks  that  communicate  with  the  subject  task,  in 
addition  to  the  abstract  algoritlun  of  the  task.  The 
relationship  of  execution  order  is  also  examined  between 
tasks  that  interact  in  order  to  detenninc  if  there  is  a 
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potential  for  deadlock,  or  starvation. 

CflfflBfcaiiflafr  “1?k  following  issues  sltould  be 

addressed  during  this  step. 

1.  Is  there  a  cycle  in  the  usage  of  tasks  (potential 
for  deadlock}? 

2.  For  selects  with  guarded  entries:  will  at  least  one 
guard  always  be  true  (if  not. 
PROGRAM..URROR  will  be  raised)? 

3.  Are  task  entry  calls  hidden  by  encapsulating 
procedures  within  tire  same  package  (to  protect 
logic  from  user)?  If  not,  will  live  use  of  tinted 
entry  calls,  or  an  abort  of  tlic  calling  task,  cause 
problctm  in  this  task’s  "select"  logic? 

4.  Can  the  value  of  a  guard  change  between  tlic 
tmte  it  is  evaluated  and  tltc  corresponding 
rendezvous? 

5.  Will  a  steady  stream  at  one  entry  block  oilier 
entries  of  task? 


be  generated  during  step  I; 


The  following  products  will 


Updated  entity  diagrams  reflecting  any 
changes  in  tlic  caller/calling  relationships. 

Ada  package  diagram  of  die  internal 
relationships  of  tlic  CSUs  within  tlic  sub¬ 
level  CSC. 


Deliverables-  SDD  Section  4.x  will  be  written 
for  each  sub-level  CSC.  Ilie  Ada  package  diagram  will 
be  included  in  this  section. 

SjgP-2  -  Specify  tlic  iinpIcniflUiujon  vfcw  of  each  S. 


This  step  provides  tlic  information  needed  to  eventually 
code  each  sub-level  CSC.  It  also  identifies  tlic  CSUs  by 
step-wise  refinement  of  tlic  sub-level  CSC. 


Refining  Descriptions  of  Processing  Entities.  For 
processing  entities  which  are  input,  output,  processing 
entities,  specify  the  processing  algoritlun  by  step-wise 
refinement.  Data  type  definitions  for  the  input  and 
output  which  were  at  an  abstract  level  during 
preliminary  design  are  now  completely  specified. 


2.  Define  tlic  implementation  of  the  operations  by 
describing  them  in  temts  of  tlicir  manipulation  of 
the  actual  object. 

3.  State  tlic  mapping  from  die  implementation  to 
tlic  cc  'ptual  view.  This  mapping  includes  how 
initialization  conditions  of  the  object  will  be 
implemented  and  how  the  consistency  rules  will 
be  maintained.  11k re  may  be  limitations  placed 
on  (Ik  implementation  view  which  were  not  pan 
of  iIk  abstract  view.  An  example  of  this  would 
be  adding  a  maximum  size  to  an  unbounded  set 
abstraction. 

4.  Verify  that  tltc  mapping  Is  consistent  and 
complete: 

a.  For  every  state  of  tltc  impleiiKiilation  of 
the  object,  is  there  a  corresponding  state 
of  iIk  abstraction? 

b.  Do  implementation  initialization  and  each 
implemented  function  maintain  the 
consistency  rules  of  iIk  abstraction? 

c.  Is  Ok  impleiiKittation  initialization 
equivalent  to  initialization  of  the 
conceptual  view? 

d.  Is  each  impleuKiitcd  operation  equivalent 
to  iIk  corresponding  coiKcptual  operation? 

Products  for  Step  .2.  TIk  following  products  will 
be  produced  during  Step  2: 

a.  PDL  for  package  bodies,  procedure 
bodies,  and  task  bodies. 

b.  PDL  for  the  select  logic  in  tlK  task 
bodies. 


Deliverables.  SDD  Sections  4.x.y  will  be  written 
for  each  CSU.  Section  S  will  be  completed. 
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For  processing  entities  that  are  objects: 

1.  Define  the  implementation  of  the  state  data  of 
tlK  object. 


56  7th  Annual  National  Conference  on  Ada  Technology  1989 


Masuos 


1.  United  States  Depattment  of  Defense,  Military 
Slumlord  Defense  System  Software  Development, 
DOD-STD-2I67A,  29  February  1988. 

2.  Uniter!  States  Department  of  Defense,  Data  Item 
Description  •  Software  Design  Document,  Dl- 
MCCR-800I2A,  29  February  1988. 

3.  Hooch,  G.,  Software  Engineering  with  Ada ,  2d 
ed„  Henjamin/Cummings  Publishing  Company, 
Inc.,  1986. 

4.  Oteny,  G.  W.,  The  I’AMEIA  Designer's 
Handbook  •  Vol.  I  it  It,  'Drought**  ‘Fools,  1986. 

5.  Nielsen,  K.,  am!  Shumate,  K.,  "Designing  Urge 
Keal-Time  Systems  with  Ada",  Communications 
of  the  ACM,  Vol.  30.  No.  8,  August  1987. 

6.  Gomaa,  II.,  "A  Software  Design  Mcthold  for 
Keal-Time  Systems",  Communications  of  the 
ACM.  Vol.  27.  No.  9,  September  1984. 

7.  Ward,  P.  ami  Mcllor,  S.,  Structured  Development 
for  Keal-Time  Systems,  Yourdan  Press,  ’985. 

8.  Scidcwitz,  E.  and  Stark,  M.,  "Towards  a  Genera! 
Object-Oriented  Software  Development 
Methodology",  Ada  Letters.  Vol.  VII,  No.  4, 
Association  for  Computing  Machinery,  Inc.,  July, 
August  1987. 


9.  Firesmith,  D„  Ada  Project  Matuigement,  1987. 

10.  United  States  Department  of  Defense,  Data  Item 
Description  •  Software  Ketiuirements  Document, 
DI-MCCR-80025A,  29  February  1988. 


Dr.  Karen  S.  Ellison  has  over  18  years  experience  in 
software  development  and  maintenance  in  both 
commercial  and  aerospace  applications.  Sl>c  is  currently 
on  contract  a;  JPt,  to  provide  day-to-day  guidance  to 
tiro  FAA  Real-Time  Wcatlror  Processor  project  on  tiro 
practical  use  of  software  engineering  nrotlrodologics  for 
rcal-tiuK,  distributed  systems  implemented  in  Ada. 


Mr.  Goulet  has  over  20  years  experience  in  tiro 
development  of  information  systems  and  embedded 
realtinro  applications.  He  is  currently  tiro  Software 
Development  Manager  for  tiro  Realtime  Wcatlror 
Processor  Project  at  tiro  Jet  Propulsion  Uboratory  in 
Pasadena,  California. 


Tiro  mailing  address  for  both  Dr.  Ellison  and  Mr. 
Goulet  is:  Jet  Propulsion  Uboratory,  California 

Institute  of  Technology,  4800  Oak  Grove  Drive,  Mai1 
Station  506-447,  Pasadena,  CA  91109. 


7th  Annual  National  Conference  on  Ada  Technology  1989  57 


LESSONS  LEARNED  IN  THE  PREPARATION  OF  A 
SOFTWARE  ENGINEERING  EXERCISE 
(A  Lite  Rift  it  SEE) 

John  P.  Fitzgibbon  and  Catherine  l’cavy 


Martin  Marietta  Information  and  Communications  Systems* 


Abstract:  Potential  Dol)  contractors  arc 
now  required  to  demonstrate  their  ability  to 
successfully  develop  software  prior  to 
contract  award.  One  mechanism  used  to 
assess  a  contractor's  capability  is  to 
complete  a  Software  Engineering  Exercise 
(SEE)  defined  by  the  procurement  agency. 
This  paper  relates  the  experiences  of  Martin 
Marietta  Information  and  Communications 
Systems  during  a  Software  Engineering 
Exercise  that  was  part  of  a  competitive 
contract  procurement.  This  paper 
summarizes  the  experience  as  lessons 
learned. 

INTRODUCTION 

Software  systems  arc  expensive,  complex  and  often 
fail  to  meet  the  basic  needs  (bat  instigate  their 
development.  Procurement  agencies,  cognizant  of 
these  problems,  have  been  concentrating  on  ways 
and  means  to  mitigate  these  risks  through  more 
careful  evaluation  of  prospective  contractors. 
Several  recent  developments  indicate  that  these 
agencies  arc  switching  emphasis  from  the  product 
to  the  process  that  creates  it.  Perhaps  the  most 
significant  development  is  a  technical  report1  by  the 
Software  Engineering  Institute  describing  a  method 
for  assessing  a  contractor's  ability  to  produce 
software.  Commissioned  by  the  Electronics  System 
Division  (ESD)  of  the  Air  Force,  this  document 
typifies  the  increasing  interest  by  the  government  in 
the  process  of  system  development. 

One  of  the  most  significant  aspects  of  DoD-STD- 
21672  js  the  requirement  that  automated 
requirements  analysis  tools  be  used  to  develop 
models  of  the  software  requirements.  These  models 
promote  understanding  and  lend  themselves  to 
analysis.  Another  trend  affecting  the  software 
engineering  process  is  the.  mandate^  to  use  Ada  for 
design  and  implementation  of  new  systems.  This 


leads  to  emphasis  on  modem  software  engineering 
principles  and  supporting  development 
environments  that  perform  evaluation  and 
verification  of  software  engineering  products.  The 
Software  Engineering  Institute  (SEI)  has 
recommended  that  contractors  be  required  to 
demonstrate  their  capability  to  undertake  software 
development  prior  to  the  commencement  of  the 
contract.  One  of  the  methods  recommended  for 
evaluation  is  a  Software  Engineering  Exercise 
(SEE). 

The  declared  purpose  of  the  SEE  is  to  provide  the 
procurement  agency  with  an  opportunity  to  evaluate 
the  offeror’s  software  development  methodology. 
The.  offeror  is  required  to  analyze  a  software 
system,  propose  a  viable  design  and  then  to  defend 
the  solution  before  a  panel  of  application  experts 
assembled  from  industry,  government  service  and 
academia.  This  allows  the  agency  to  make  an 
objective  appraisal  of  the  quality  of  the  product, 
and  the  efficacy  of  the  development  procedures  and 
practices.  Furthermore,  it  allows  the  procurement 
agency  insight  into  management  cffcctivity. 

The  problem  for  this  exercise  involved  developing 
a  Real-Time  executive  that  would  support  the 
control  and  execution  of  a  distributed  simulation. 
The  offeror  was  directed  to  provide  a  complete 
software  architecture  outlining  each  major  design 
component,  to  perform  detailed  software 
requirements  analysis  on  at  least  two  of  the  major 
architectural  components,  develop  a  top-level 
design  for  the  analyzed  components  and  to  provide 
a  detailed  design  for  at  least  one  element.  The 
executive  was  to  be  designed  in  such  a  manner  that 
it  would  be  implcmcntable  in  Ada.  Furthermore, 
the  design  of  low  level  software  elements  was  to  be 
expressed  as  compilable  Ada  PDL.  The  instructions 
to  the  offeror  also  stated  that  documentation  should 
be  representative  of  the  offeror's  software 
development  methodology.  Although  the 
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documentation  could  be  informal,  the  instructions 
implied  that  information  provided  by  a  Software 
Requirements  Specification  (SRS),  a  Software  Top- 
Level  Design  Document  (STLDD)  and  and  a 
Software  Detailed  Design  Document  (SDDD)  was 
expected. 

Following  suumission  of  the  offeror’s  engineering 
documentation  the  procurement  agency  evaluated 
the  solution.  Once  the  agency  had  evaluated  the 
submitted  ’ita,  a  review  was  scheduled  to  provide 
the  offero1  .he  opportunity  to  describe  the  results 
of  the  engineering  analysis  and  design.  'Hie  offeror 
was  allowed  two  hours  to  present  analyses, 
interpretations  of  requirements,  design  descriptions 
and  to  describe  alternative  design  approaches.  'Hie 
presentation  was  followed  by  a  five  hour 
examination  of  the  requirements  analysis,  software 
design  and  the  participants  in  the  exercise.  'Hie 
remainder  of  this  paper  recounts  the  experiences 
that  Martin  Marietta  had  during  the  performance  of 
a  Software  Engineering  Exercise. 

LESSONS 

While  our  efforts  on  the  SEE  were  successful  in  the 
acquisition  of  the  contract,  we  feel  that  with  belter 
preparation  our  results  could  have  been  better.  The 
following  sections  detail  what  we  feel  arc  the  most 
important  lessons  derived  from  the  execution  of  the 
exercise.  Although  the  lessons  were  particular  to 
the  SEE,  some  reflection  shows  that  (hey  arc 
applicable  to  the  Software  Engineering  process  in 
general.  These  lessons  represent  management 
principles  but  they  arc  rendered  from  the 
perspective  of  a  software  engineering  practitioner. 

Software  Engineering  managers  should  carefully 
consider  these  lessons  so  that  they  may  better 
understand  the  implications  of  their  actions  on  their 
staff,  the  product  and  the  process  of  development. 

Never  try  to  pick  up  two  watermelons  at  the 
same  time 

The  prospective  bidder  is  faced  with  two  different 
problems  in  the  preparation  of  a  Software 
Engineering  Exercise  (SEE).  The  first  problem  is 
the  analysis  of  the  problem  and  synthesis  of  a 
design.  However,  the  second  and  more  important 
problem  is  to  select  and  apply  a  suitable 
development  methodology  to  the  development 
process.  Most  companies  have  established  software 
engineering  methodologies  that  have  evolved  over  a 
number  years  in  response  to  contract  experience.  It 
is  a  very  rare  case  when  this  experience  base 
includes  a  dozen  or  more  large  scale  Ada 


development  projects.  Therefore,  most  companies 
are  in  the  unfortunate  situation  of  having  to  update 
their  current  practices  and  procedures  to 
accommodate  Ada  and  DoD-STD-2167 
requirements.  Since  the  scope  of  this  task  clearly 
exceeds  the  time  limitations  imposed  by  a 
competitive  procurement,  it  is  necessary  to  workout 
the  software  methodology  in  advance. 

Now  that  the  contractor  has  defined  a  modern 
software  development  methodology  it  only 
remains  to  assemble  a  team.  'Ibis  team  must  be 
familiar  with  the  application  area  and  skilled  in  the 
application  of  the  selected  software  development 
methodology.  There  may  be  companies  rich  with 
an  abundance  of  highly  skilled  software 
professionals,  couched  in  the  most  modern 
development  methodologies,  who  are  instantly 
available  to  respond  to  proposals.  (If  there  are  such, 
they  would  be  immediately  disqualified  out-of-hand 
if  the  procurement  agency  suspects  that  "ringers" 
have  been  brought  in.)  For  the  rest  of  us,  we  have 
no  alternative  other  than  training  our  staff  in  the 
principles,  techniques,  and  tools. 

Participants  in  a  Software  Engineering  Exercise 

(SEE)  should  provide  a  Software  Development  Plan 

(SDP)  as  one  of  the  deliverable  documents  even  if  it 
is  not  specifically  required.  Submission  of  a  SDP 
provides  the  contractor  an  opportunity  to  explain 
the  software  methodology  used  during  the  SEE. 
The  real  purpose  of  the  SEE  is  to  showcase  the 
software  development  methodology  rather  than  the 
product.  Tire  proposal  section  of  the  SEE  response 
should  relate  how  application  of  the  selected 
development  approach  lead  to  the  resultant  solution 
to  the  software  engineering  problem. 

We  recommend  that  the  SDP  be  prepared  in 
advance  due  to  the  time  pressures  inherent  in  a 
competitive  procurement.  This  docs  not  imply  that 
the  contractor  has  a  single  methodology  that  it 
applies  to  each  of  the  projects  undertaken  by  the 
offeror.  On  the  contrary,  we  suggest  that  the 
offeror  develop  a  standard  set  of  procedures, 
encompassing  several  development  paradigms,  that 
may  be  selected  and  integrated  into  a  software 
development  methodology  that  is  tailored  to  the 
specific  needs  of  a  particular  project.  'Ibe  SDP  is 
in  effect,  a  template  referencing  a  set  of  possible 
techniques  and  procedures  that  may  be  selected  to 
provide  several  variant  sequences  of  development 
activities  each  of  which  is  appropriate  for  a  given 
development  paradigm.  Along  with  the  set  of 
procedures  is  a  set  of  rules  that  provide  constraints 
on  the  various  combinations  of  procedures.  For 
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example,  there  may  not  be  a  proven  methodology 
that  combines  Object  Oriented  Analysis,  Jackson 
System  Design  method  and  Top-Down  system 
development. 

The  real  lesson  is  that  without  establishing  software 
development  procedures,  techniques  and  methods  in 
advance,  the  application  experts  will  not  be 
effective  in  solving  the  designated  engineering 
problem.  Next,  the  development  team  must  be 
trained  in  the  methods  and  procedures  composing 
the  methodology.  Finally,  this  system  of 
engineering  processes  must  be  proven  in  actual 
practice  since  the  methodology  will  be  evaluated  by 
the  quality  of  tire  resultant  product.  Understanding 
that  the  system  problem  space  is  coupled  to  the 
engineering  process  space  is  critical  in  assuring 
success  of  the  development  effort. 

Do  not  try  to  cat  the  elephant  in  one  bite 

Problem  descriptions  used  during  a  SUE  tend  to 
have  very  large  scope  and  be  somewhat  ambiguous. 
It  is  not  unusual  for  there  to  be  conflicting 
statements  within  the  problem  definition. 
Furthermore,  the  offeror  can  be  prohibited  from 
asking  questions  regarding  the  meaning  of  the 
problem  statement  or  other  requirements 
specifications.  Given  these  conditions  it  is  difficult 
to  control  the  engineering  process.  We  believe  that 
to  sonic  extent  this  is  a  premeditated  action  on  the 
part  of  the  procurement  agency  designed  to  evaluate 
the  offeror's  management  ability.  Therefore,  the 
offeror  should  interpret  the  requirements  so  that  a 
solution  may  be  achieved  within  given  time  and 
available  resources. 

The  SEE  instructions  provide  the  offeror 
considerable  latitude  in  requirements  interpretation 
and  the  scope  of  problem  analysis.  'Hie  key  to 
success  is  to  develop  a  consistent  strategy  for  the 
course  of  analysis.  The  first  premise  is  that  not  all 
aspects  of  a  problem  arc  equally  important. 
Therefore,  the  analysts  must  prioritize  different 
problem  aspects,  high-lighting  the  most  critical 
ones.  The  analysis  in  these  areas  should  progress 
first  and  to  the  greatest  depth.  For  less  important 
areas  the  analysis  should  be  deferred  until  the  rest 
of  the  problem  is  better  understood.  For  those  less 
critical  areas,  the  analysts  should  make  assumptions 
that  will  simplify  the  resultant  design.  This  strategy 
leads  to  systems  that  arc  simpler,  more 
understandable  and  ultimately  easier  to  operate  and 
maintain.  In  the  context  of  the  SEE,  this  leads  to  a 
problem  definition  that  is  tractable  within  the 
available  time  and  resources. 


Some  readers  may  argue  that  the  offeror  docs  not 
have  the  right  to  make  interpretations  of  the  system 
specification  or  to  decide  what  is  more  or  less 
important.  However,  ambiguous  specifications  are 
common  itt  our  industry  and  are  often  the  result  of 
ambivalence  on  the  part  of  the  customer  or  an 
attempt  to  reach  consensus  between  different 
factions.  By  providing  a  "strawman",  the  dialogue 
between  the  customer  and  the  contractor  is 
transported  from  an  abstract  plane  to  specifics.  'I1k 
contractor  can  present  alternatives  that  may  not 
have  been  feasible  when  the  need  for  tltc  system  was 
first  realized  and  specified.  Moreover,  this  allows 
the  analysis  process  to  proceed  to  closure. 

Each  journey  begins  with  the  first  step 

'Hie  purpose  of  the  SEE  is  to  demonstrate  the 
effectiveness  of  the  offeror's  software  development 
process.  An  important  part  of  this  process  is  the 
generation  of  engineering  data  products.  Although 
the  instructions  to  the  SEE  problem  allow  the 
offeror  to  provide  informal  documentation,  we 
chose  to  develop  documentation  as  required  by 
DoD-STD-2167.  By  doing  so  we  provided 
documentation  that  would  be  representative  of  that 
prepared  under  any  future  contract  with  this 
customer.  Furthermore,  this  reinforces  our 
premise  that  documentation  is  a  normal  product  of 
the  software  engineering  process  rather  than  an 
obligatory  and  onerous  task  that  has  nothing  to  do 
with  the  process.  However,  the  first  step  in  the 
engineering  process  is  to  analyze  the  total  system 
(i.c.,  software  hardware  and  manual  operations) 
and  define  how  it  will  be  used. 

We  elected  to  develop  a  System  Segment 
Specification  (SSS)  and  an  Operational  Concept 
Document  (OCD)  in  addition  to  the  software 
specifications  and  design  documents.  We  believe 
that  the  Systems  Engineering  analysis  and  the 
Software  Engineering  Analysis  arc  interdependent 
processes  that  form  a  unified  development 
methodology.  The  Systems  Engineering  process 
generates  an  essential  understanding  of  the  context 
surrounding  the  software  product.  Without 
performing  adequate  Systems  Engineering  analysis 
prior  to  software  engineering,  designers  have  little 
guidance  in  the  development  of  a  realistic  solution. 

One  of  the  most  important  products  of  the  System 
Engineering  Analysis  is  the  Operational  Concept 
Document  and  as  such  requires  special  attention  in 
this  discourse.  Consider  a  distributed  system 
architecture  comprising  a  central  host  that  processes 
information  and  a  network  of  satellite  workstations 
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(hat  display  the  information  and  provide  system 
control.  Should  the  system  design  employ 
centralized  control  or  distributed  control?  Should 
the  workstations  be  uniquely  configured  to  perform 
a  specific  subset  of  functions  or  should  each 
workstation  provide  all  of  the  functions  that  are 
required  by  the  set  of  all  possible  users?  Should  the 
human  machine  interface  be  designed  to 
accommodate  the  least  trained  user  or  should 
responsive  performance  be  emphasized  or  must  the 
interface  exhibit  either  behavior  depending  upon 
the  requirentents  of  the  user?  Is  it  necessary  for  the 
system  to  operate  in  more  than  one  mode 
concurrently?  Should  different  system  modes  be 
physically  partitioned  so  that  there  is  no  chance  of 
confusion  or  cross-over?  The  Operational  Concept 
Document  provides  a  framework  to  evaluate  these 
design  alternatives  by  defining  who  will  use  the 
system,  how  it  will  be  employed  and  deployed  and 
which  system  requirements  arc  satisfied  by  manual 
procedures. 

Bigger  is  not  better 

One  of  the  most  frequently  recurring  patterns  of 
organization  among  successful  projects  is  a  smalt 
design  team  that  participates  in  all  phases  of 
development.  Frederick  Brooks4  described  the 
chaos  that  resulted  front  trying  to  employ  a  huge 
team  of  1,000  software  programmers  to  design 
OS/360.  Little  progress  was  made  until  the  design 
became  the  responsibility  of  a  12  member 
architecture  team.  On  the  contrary,  Harlan  Mills 
demonstrated  that  a  small  team  of  specialists  could 
design  a  system  of  similar  size  (New  York  Times 
operating  system*)  in  a  shorter  time  interval  and 
with  higher  product  quality. 

The  team  we  selected  consisted  of  a  small  kernel  of 
individuals  who  were  well  trained  and  had  been 
working  together  for  over  a  year  prior  to  the  SEE. 
We  recommend  that  the  team  comprises  specialists 
in  each  of  the  skill  categories  related  to  the  project. 
Skill  categories  might  include  a  language  specialist, 
a  data  base  designer,  an  application  expert,  a 
requirements  analyst,  and  a  system  designer. 

Another  category  that  is  becoming  increasingly 
important  is  a  software  engineering  tool  specialist. 
This  individual  is  an  expert  in  the  engineering 
techniques,  analysis  methods  and  the  tools  that 
support  the  constituent  parts  of  the  selected 
engineering  methodology.  In  a  long  term  project, 
this  individual  may  also  play  the  role  of  a  software 
engineering  toolsmith  tasked  with  automating 
portions  of  the  process.  If  we  had  had  such  a 


specialist  during  the  SEE,  we  would  have  better 
exploited  the  capabilities  of  our  engineering  tools 
and  had  better  productivity. 

Modern  workstations,  analysis  tools,  word 
processors,  graphics  tools,  and  other  facets  of  desk 
top  publishing  arc  of  limited  use  if  the  staff  and 
management  are  unaware  of  their  capabilities  and 
unable  to  exploit  such  tools  fully.  With  this  in  mind 
we  recommend  that  the  development  staff  be 
supported  by  a  complement  of  administrative  aides, 
'litis  support  team  should  comprise  commercial 
artists  trained  in  computer  graphics,  word 
processing  clerks  capable  of  editing  technical 
manuscripts,  and  engineering  aids  trained  to  execute 
engineering  procedures  effectively.  Hie  supporting 
staff  should  work  with  the  development  team  rather 
than  be  quartered  in  a  clerical  pool.  During  the 
SEE,  our  support  staff  was  located  at  some  distance 
from  the  development  team.  Consequently,  we  had 
to  use  engineering  talent  for  several  eh  ical  tasks, 
litis  effort  would  have  been  better  employed  doing 
engineering  tasks. 

Once  the  team  has  been  selected,  management  must 
trust  them  to  accomplish  their  task  through  self- 
direction.  Management  needs  to  monitor  progress 
and  assure  that  resources  are  available  when  they 
are  needed.  In  most  eases,  the  team  members  are 
the  ones  most  qualified  to  decide  what  resources  are 
needed  and  how  they  should  be  applied. 

Teach  old  dogs  new  tricks 

Although  the  team  should  be  self-directed  to  the 
greatest  extent  possible,  management  must  retain 
visibility  into  the  development  process.  A 
development  team  can  easily  lose  track  of  its 
primary  objectives  by  becoming  too  engrossed  with 
tangential  issues  and  minor  details  of  the  problem. 
At  this  point  management  must  be  capable  of 
stooping  in  and  moving  the  development  back  on 
track.  To  do  this  Engineering  Management  must 
understand  the  methods  being  used  by  the  design 
team  and  develop  methods  and  metrics  to  monitor 
the  on-going  process.  This  means  that  training  for 
Engineering  Management  is  a  critical  priority  and 
that  this  training  must  include  modem  development 
methodology  as  well  as  management  issues. 

Engineers  find  it  difficult  to  separate  the  process  of 
requirements  analysis  and  design.  We  believe  that 
while  a  partial  cause  for  this  phenomena  lies  with 
inadequate  training  and  personal  disposition, 
another  cause  is  the  fact  that  the  two  processes  arc 
interdependent.  Rather  than  inhibit  the  creativity  of 
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the  developers  by  enforcing  an  arbitrary  separation 
of  the  processes  we  decided  to  allow  iteration 
between  the  two  processes.  Tltc  team  was  allowed  to 
iterate  freely  between  analysis  and  design  with  the 
stipulation  that  their  perambulations  were  recorded 
in  engineering  notebooks.  These  notebooks 
provided  the  source  material  for  the  engineering 
data  products  required  by  DoD-STD-2167. 

*1110  conversion  of  source  material  to  standard 
documentation  format  was  done  by  a  small  team  of 
specialists  acting  as  technical  writers.  'litis  allowed 
us  to  uncouple  the  design  process  from  the 
recording  process.  It  is  tempting  to  suggest  that  the 
writing  team  be  composed  of  non-engineering  talent 
so  that  labor  costs  can  be  reduced.  1  lowever,  we 
would  prefer  to  use  experienced  design  engineers. 
We  discovered  that  the  design  team  was  not  always 
rigorous  in  the  maintenance  of  the  design  notebooks 
and  that  the  writing  team  had  to  interact  with  the 
designers  to  get  necessary  information.  The 
resulting  dialogue  forced  the  design  team  to 
consider  the  validity  of  the  candidate  design  and  to 
consider  possible  alternatives.  If  tl»-  writing  (cam 
had  not  i  ,.t  composed  of  top  quality  software 
engineers,  the  dialogue  might  have  degenerated  into 
a  monologue  and  have  added  little  value. 

Substance  before  style 

The  most  important  thing  a  participant  in  a 
Software  Engineering  Exercise  can  do  to  improve 
the  quality  of  their  response  is  to  check  the 
submitted  documentation  for  consistency.  During 
the  SEE  we  learned  to  appreciate  the  value  of  using 
Engineering  Analysis  tools  to  verify  interfaces 
between  software  components.  We  prepared 
requirements  traceability  matrices  mapping  system 
requirements  to  design  components.  Due  to  the 
limited  scope  of  the  problem  we  were  able  to 
perform  this  task  manually.  However,  we  learned 
that  this  becomes  unmanageable  for  any  problem 
that  is  realistically  sized.  Since  that  time  we  have 
directed  some  research  effort  into  developing 
generalized  data  base  models  to  generate  the 
necessary  traceability  reports  automatically. 

During  the  SEE  we  had  different  groups  working 
on  the  requirements  analysis  and  system  design. 
This  enabled  parallel  development  to  some  extent 
while  on  the  other  hand  it  created  problems  with 
consistency  of  documents.  This  is  essentially  no 
different  than  development  under  traditional  life- 
cycle  paradigms  where  requirements  analysis  and 
design  arc  partitioned  by  time  if  not  personnel.  We 
were  able  to  control  this  parallel  development  by 


the  requiring  that  the  two  groups  exchange 
documents  for  review.  This  interchange  of 
information  improved  the  work  of  both  groups  and 
promoted  consistency  of  documentation  style,  form 
and  content. 

While  attention  to  style  and  format  can  make  a 
good  product  sparkle,  it  must  never  be  substituted 
for  accuracy  of  content.  In  an  effort  to  enhance  the 
polish  of  our  submitted  documentation,  we  passed 
up  a  final  opportunity  to  review  the  documents  for 
technical  consistency.  One  of  the  most  painful 
experiences  of  the  SEE  for  our  team  was  the 
discovery  of  errors  after  submission  of  our 
response.  These  errors  were  the  direct  result  of 
polishing  an  incomplete  product. 

Measure  your  bucket  before  bailing 

Performance  analysis  should  be  started  as  soon  as  a 
candidate  software,  architecture  is  sketched  out. 
When  there  arc  no  Quantitative  Performance 
Requirements  (QPR's)  provided  with  the  problem 
statement,  the  engineering  team  should  make 
assumptions  regarding  reasonable  performance 
based  upon  experience  and  similar  systems.  The 
Operational  Concept  will  often  provide  valuable 
insight  into  what  the  customer  expects  of  the 
system.  Using  mathematical  analysis  or  simulation  it 
is  possible  to  quickly  determine  performance  for 
the  major  system  behaviors. 

There  arc  certain  figures  of  merit  that  can  be 
derived  by  simple  means  that  provide  valuable 
information  on  expected  system  performance.  The 
first  figure  is  the  mean  time  for  task  context  switch. 
This  can  be  computed  with  an  Ada  program 
consisting  of  two  or  more  tasks.  The  program  is 
written  so  that  the  tasks  rendezvous  with  each  other 
in  a  circular  configuration  (c.g.,  A  =>  B  =>  C  =>A 
...).  A  loop  of  1,000,000  is  appropriate  for 
machines  that  execute  at  the  rate  of  one  million 
instructions  per  second  (l  MIP).  Task  rendezvous 
rates  of  1000  per  second  are  typical  for  such  an 
environment.  A  variant  of  this  figure  is  the  mean 
time  for  process  context  switch.  This  is  determined 
in  a  similar  manner  by  having  processes 
communicate  rather  than  Ada  tasks.  This  is 
especially  relevant  for  systems  that  employ 
multiple-processor  architectures. 

Another  necessary  figure  of  merit  is  the  maximum 
effective  data  rate  for  each  data  link  in  the 
distributed  system.  This  can  be  determined  by  a 
simple  program  consisting  of  two  cooperating 
processes  that  continuously  exchange  messages 
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without  performing  any  information  processing. 
The  effective  data  rate  should  be  plotted  as  a 
function  of  average  message  size  for  each  data  link 
in  the  system.  For  data  links  that  use  multiple 
access  channel  acquisition  (e.g.,  Ethernet)  it  is 
important  to  parameterize  the  effect  of  channel 
contention  on  performance.  This  can  be  done  by 
testing  pairs  of  cooperating  processes  or  developing 
a  test  program  variant  that  communicates  with  an 
arbitrary  number  of  clients. 

The  results  of  a  performance  analysis  may  be 
disturbing  to  the  design  team.  As  a  result  of  this 
analysis,  we  determined  that  no  more  than  two  (ask 
rendezvous  could  be  tolerated  for  a  single 
transaction.  We  modified  our  design  accordingly 
and  used  buffering  to  minimize  communication 
overhead.  Regardless  of  the  outcome,  we  feel  that 
performance  analysis  data  should  always  be 
presented  as  part  of  the  response  to  the  SEE 
problem.  A  perceptive  customer  will  expect  it  to  be 
there  and  question  its  absence. 

Practice  makes  perfect 

If  there  is  one  thing  that  we  wished  that  we  had 
done  in  preparation  for  our  first  Software 
Engineering  Exercise  it  would  have  been  to  practice 
in  advance.  Ideally,  we  would  have  chosen  a  design 
team  and  practiced  by  performing  mock  SEE's 
internally.  This  would  promote  self-confidence  on 
the  part  of  the  design  team  as  well  as  pointing  out 
deficiencies  in  time  to  take  effective  action.  Even  if 
the  team  has  been  thoroughly  trained  in  the 
principles  of  software  methodology,  there  is  no 
substitute  for  actual  experience  with  a  SEE. 

Having  gone  through  a  SEE  we  have  gained 
considerable  respect  for  its  ability  to  point  out 
problems  with  the  software  development  process 
and  evaluating  die  effectiveness  of  a  design  team. 
We  think  that  this  technique  should  be  used  to 
evaluate  new  software  methodologies,  research  and 
development  projects,  to  validate  new  software 
standards  and  practices,  and  to  evaluate  software 
engineering  tool  products.  In  addition  to  self- 
evaluation,  we  think  that  the  SEE  format  is 
particularly  effective  in  predicting  the  performance 
of  sub-contractors.  Furthermore,  experience 
gained  applying  this  technique  to  others  will 
provide  valuable  knowledge  and  insight  on  the  most 
effective  way  to  execute  a  SEE  as  part  of  a 
competitive  procurement. 


Money  for  nothing  and  checks  for  free 

The  contractor  should  consider  the  statement  of  the 
SEE  problem  very  carefully  before  beginning  to 
frame  a  response.  'Hie  procurement  agency  will 
surely  have  chosen  what  it  considers  to  be  die  most 
difficult  technical  problem  for  die  real  system  that 
is  being  procurrcd.  The  government  is 
understandably  trying  to  get  a  head  start  on  the 
development  of  his  system  during  the  competitive 
phase  of  the  procurement.  In  doing  so,  he  is 
dropping  clues  regarding  what  lie  considers  to  be  an 
appropriate  answer.  The  nature  of  the  SEE 
problem  statement  exposes  the  government's  real 
for  technical  evaluation.  'Hie  mainline  proposal 
team  can  and  should  use  this  intelligence  in  framing 
their  proposal.  Similarly,  the  SEE  team  should 
examine  the  RFP  and  the  proposal  for  guidance  in 
their  response.  The  SEE  team  should  choose  a 
design  approach  that  can  arguably  be  extended  to 
work  with  or  be  part  of  the  "Real"  system.  Their 
response  should  emphasize  commonalty  shared  by 
the  "Real"  system  and  the  SEE  system. 

An  ounce  of  prevention  has  more  value  than 
a  ton  of  remorse 

Once  the  SEE  team  has  submitted  their  final  draft, 
it  is  time  to  start  preparing  for  the  Review  panel. 
The  first  step  in  this  preparation  is  to  have  each 
member  of  the  SEE  team  read  every  document  that 
was  submitted  with  the  response.  This  should  be  a 
critical  review  where  each  team  member  is  trying 
to  discover  flaws  in  the  approach  or  documentation. 

While  reviewing  the  submitted  documents,  the  SEE 
team  should  make  a  list  of  deficiencies,  missing 
data,  errors  and  other  questions  that  arc  not 
adequately  addressed.  'Pie  SEE  team  should  then 
try  to  provide  written  answers  to  each  question  on 
the  list.  If  an  error  was  simply  an  oversight  then  it 
is  best  to  admit  it  and  to  say  that  it  was  identified 
during  the  post-submission  review.  Participants  of 
a  Software  Engineering  Exercise  arc  very  aware  of 
the  unusual  time  pressures  resulting  from  this 
situation.  In  our  own  experience  we  successfully 
predicted  approximately  half  of  the  technical 
questions  presented  at  the  review. 

Another  task  is  to  find  out  as  much  as  possible 
about  the  team  of  "Grey  Beards"  who  will  be  on  the 
review  panel.  Several  of  them  will  be  academics; 
reading  their  recently  published  papers  will  provide 
insight  into  what  they  will  ask.  'Pie  other  members 
of  the  review  panel  will  be  military  and  civilian 
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employees  of  the  procurement  agency.  In  most 
eases,  someone  in  your  organization  has  dealt  with 
them  before  and  can  define  the  hot  buttons. 

The  best  way  to  prepare  the  SEE  team  for  the 
actual  conduct  of  the  "Grey  Beard"  review  is  to 
stage  a  dry  run.  The  contractor  should  select  a 
Technical  Review  team  consisting  of  senior 
technical  staff  and  executive  level  managers  from 
other  projects.  The  Technical  Review  team  will 
play  the  role  of  the  "Grey  Beards"  during  tire  dry 
run.  To  aid  the  Technical  Review  team  in 
preparing,  the  SEE  team  should  provide  the  list  of 
questions  and  answers  generated  during  the 
document  review.  These  questions  will  provide  the 
reviewers  with  an  introduction  to  the  SEE  problem 
and  the  critical  aspects  of  its  proposed  solution. 
Moreover,  it  will  stimulate  the  thought  processes  of 
the  review  panel  in  defining  their  own  questions.  If 
the  SEE  team  can  survive  such  ait  iitquisition  then  it 
should  be  well  prepared  for  the  actual  review. 

After  the  dry  run,  the  SEE  team  and  the  Technical 
Review  team  should  meet  for  a  debriefing.  The 
purpose  of  the  debriefing  is  to  assess  the 
preparedness  of  the  SEE  team.  The  Technical 
Review  team  should  provide  answers  to  any 
questions  that  the  SEE  team  failed  to  answer 
adequately.  The  SEE  team  should  also  ask  the 
Technical  Review  team  to  help  answer  any 
unresolved  questions.  The  management  members 
of  the  Technical  Review  team  tend  to  be  very  adept 
at  providing  answers  to  impossible  technical 
questions. 

The  "Tools  'R  Us"  Syndrome 

Too  many  discussions  of  software  engineering 
methodology  begin  and  end  with  tools.  Available 
tools  far  too  often  define  and  mandate  the  choice  of 
a  particular  methodology  rather  than  the  intrinsic 
nature  of  the  problem  under  study.  Lack  of 
adequate  tools  to  support  a  particular  methodology 
may  discourage  engineering  management  from 
applying  the  most  appropriate  methodology.  On  the 
other  hand,  the  desire  to  use  the  latest  hot 
methodology  can  lead  to  a  precipitous  choice  of 
engineering  tools  based  solely  on  the  felicitous 
assertions  or  a  CASE  vendor. 

A  software  engineering  methodology  comprises  a 
development  strategy,  techniques  for  analysis,  tools, 
standards,  metrics  and  appropriate  training.  Success 
requires  that  each  item  be  addressed  carefully  and 
that  none  be  shorted.  In  particular,  the  training 
budget  should  never  be  sacrificed  for  the  benefit  of 
any  other  aspect  of  development.  Time  and  again, 


dollars  spent  on  training  have  had  the  greatest  pay¬ 
back.  Dollars  saved  on  training  have  borne  the 
greatest  cost. 

A  development  strategy  or  paradigm  should  be  the 
most  carefully  considered  decision  of  any 
engineering  process.  The  development  strategy  is 
the  pattern  that  unifies  the  analysis  methods,  tools, 
standards  and  metrics  that  arc  applied  to  problem 
resolution.  If  an  Object  Oriented  methodology  were 
employed,  we  might  expect  the  choice  of  such 
engineering  disciplines  as  Object  Oriented  Analysis, 
Information  Modeling,  and  Object  Oriented 
Programming  practices.  To  support  these  methods 
we  would  require  an  Object  Oriented  Language  and 
tools  to  develop  and  analyze  Entity  Relationship 
Diagrams.  Standards  and  metrics,  supported  by 
other  tools,  would  instrument  the  engineering 
process  and  aid  in  the  evaluation  of  the  software 
products.  No  matter  what  paradigm  is  chosen,  it  is 
critical  that  it  be  complete.  Each  method,  tool  and 
procedure  must  be  compatible  with  and  complement 
each  element  of  the  methodology. 

Techniques  or  methods  are  forms  of  analysis  that 
describe  some  aspect  of  the  problem  under  study. 
Usually  these  techniques  employ  engineering 
models  that  emphasize  the  attributes  under  study 
while  diminishing  or  ignoring  other  aspects.  Since 
these  models  and  techniques  focus  on  singular 
attributes  it  is  not  possible  for  any  one  method  to  be 
comprehensive.  A  given  methodology  may 
incorporate  Structured  Analysis,  Structured  Design, 
Structured  Testing  and  Top-Down  development. 
This  is  not  the  only  feasible  methodology  nor  is  it 
appropriate  for  all  projects.  These  methods  need  to 
be  selected  based  on  the  nature  of  the  problem 
under  study  and  the  personnel  performing  the 
analyses. 

Tools  support  a  specific  technique  by  providing  a 
mechanism  to  depict  and  analyze  the  engineering 
model.  Structured  Analysis  uses  a  model 
comprising  a  set  of  Data  Flow  Diagrams  (DFD's),  a 
data  dictionary  and  a  set  of  process  specifications. 
The  tool  must  support  each  of  these  aspects  of  the 
model  and  aid  in  its  analysis.  At  a  minimum,  it 
must  be  able  to  cross-validatc  the  DFD's,  the 
dictionary  and  the  Input/Output  declarations  of  the 
processing  specification.  Furthermore,  it  must  be 
able  to  verify  consistency  of  expression  between 
different  levels  and  partitions  of  the  set  of  DFD's. 
Other  useful  capabilities  include  normalization  of 
data  flow  definitions  within  the  data  dictionary, 
reports  that  specify  data  elements  crossing 
interfaces,  mechanisms  that  allow  capture  and 


64  7th  Annual  National  Conference  on  Ada  Technology  1989 


retrieval  of  auxiliary  data  attributes  (c.g.,  range, 
accuracy  ...)  and  analyses  of  change  activity  on 
different  portions  of  the  model.  'Hie  point  of  the 
foregoing  discussion  is  to  demonstrate  that  the 
outputs  of  tools  should  be  verifiable  and  that  they 
should  directly  map  to  products  required  by  the 
engineering  process. 

Standards  provide  a  set  of  criteria  by  which  to 
compare  the  quality,  consistency  and  completeness 
of  engineering  products.  Most  projects  have  coding 
standards  that  prescribe  presentation  format,  usage 
of  language  features,  and  naming  conventions. 
However,  far  fewer  projects  have  standards  that 
address  the  partitioning  of  requirements  models, 
allocation  of  requirements  to  components, 
appropriate  levels  of  design  decomposition,  detail 
requirements  for  process  specifications  or  provide 
criteria  by  which  to  evaluate  test  eases.  For  a 
methodology  to  be  effective,  standards  must  exist  to 
evaluate  each  product  and  activity  included  in  the 
methodology. 

Metrics  provide  a  standard  to  measure  the  state  of 
the  engineering  process.  Most  metrics  that  have 
been  defined  relate  only  to  the  implementation 
activity.  The  most  often  cited  metric  is  the  Line  of 
Code  (LOC)  statistic.  Most  managers  can  quote 
program  productivity  rales  (c.g.,  2  LOC/hour)  but 
few  have  any  idea  of  what  acceptable  error  density 
rates  might  be  (50  per  1000  LOC  ?).  Furthermore, 
how  can  we  measure  other  engineering  activities 
such  as  requirements  analysis  or  test?  Good  metrics 
should  provide  management  with  answers  to  the 
following  questions.  How  far  have  we  gone?  How 
much’furthcr  must  we  go?  At  what  rate  arc  we 
approaching  completion?  Suitable  metrics  for  each 
engineering  activity  and  process  must  be  developed 
and  applied  in  the  context  of  the  tools  and  methods 
that  compose  the  selected  engineering  methodology. 

CONCLUSIONS 

This  paper  recounts  the  experiences  of  Martin 
Marietta  Information  and  Communication  Systems 
while  performing  a  competitive  Software 
Engineering  Exercise.  However,  many  of  the 
lessons  learned  are  applicable  to  the  management  of 
any  engineering  process.  To  succeed  in  coming 
years  companies  will  require  a  large  number  of 
well  trained,  dedicated  engineering  professionals. 
The  number  required  and  the  market  demand  for 
such  individuals  implies  that  it  will  not  be  feasible 
to  hire  all  of  them.  Instead,  companies  must  develop 
training  programs  for  their  existing  work  force. 


The  software  engineering  process  is  changing 
rapidly  due  to  growth  of  requirements  and 
revolutionary’  .advances  in  technology.  To  cope  with 
and  to  understand  the  nature  of  this  change, 
companies  will  have  to  invest  in  tlte  acquisition  ami 
transfer  of  modern  engineering  technology.  This 
requires  research  into  software  engineering 
processes,  the  interdependencies  among  analysis 
methods,  standards  to  evaluate  engineering  products 
and  metrics  that  instrument  the  process  of 
development.  'lire  results  of  this  research  must  be 
codified  into  new  engineering  practices,  standards 
and  procedures.  Once  developed  these  engineering 
practices  must  be  validated  through  real  world 
application  by  projects.  Feedback  from  the  projects 
will  assure  that  research  programs  arc  investigating 
the  most  important  problems  and  that  new 
procedures  arc  effective. 

Tire  engineering  process  can  no  longer  be  viewed  as 
separate  activities  performed  by  isolated  specialists 
but  rather  as  a  single  process  executed  by  a  team  of 
generalists.  The  members  of  future  development 
teams  will  be  schooled  in  all  the  skills  necessary  to 
engineer  software  systems  including  analysis, 
design,  implementation,  test  and  integration.  The 
same  team  will  be  responsible  for  the  product  from 
concept  evaluation  through  deployment. 
Consequently,  staff  loading  will  be  more  stable 
throughout  the  project  life  and  productivity  will  be 
higher.  The  impact  to  the  product  will  be  higher 
quality,  lower  cost  and  sooner  availability. 

The  development  processes  must  become  more 
flexible  ihan  current  paradigms  allow.  Rather  than 
a  single  methodology,  based  on  a  standard  paradigm 
comprising  a  small  set  of  methods,  modern 
methodologies  will  comprise  a  rich  set  of  various 
disciplines.  These  methods  will  form  rsts  of 
interchangeable  process  components.  The 
components  will  form  an  integrated  system  bound 
by  a  paradigm  that  is  tailored  to  specific  product 
features  and  program  needs.  In  this  manner, 
different  methodologies  can  be  applied  to 
accommodate  technical  risk,  project  resources  and 
applicable  technology. 
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To  succeed,  companies  and  employees  must  exhibit 
an  unwavering  commitment  to  professional 
excellence.  Employees  must  be  trained  and  nurtured 
to  bring  out  their  full  potential.  Employees  must  be 
willing  to  dedicate  considerable  energy  to  learn, 
master  and  apply  new  technology  as  it  becomes 
available.  Methods  for  monitoring  employee 
development  and  rewarding  progress  must  be 
instantiated.  Furthermore,  companies  must  provide 
an  environment  in  which  employees  can  excel  and 
they  must  be  unwilling  to  accept  anything  other 
than  superior  performance. 
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ABSTRACT 

A  series  of  descriptions  of  software  development 
methods,  based  on  data  obtained  from  their  suppliers, 
is  presented  as  on  example  of  a  basis  for  comparing 
methods.  In  this  approach,  method*  rather  than  their 
product*  are  compared.  The  method*  described  were 
selected  because  they  arc  intended  to  help  software 
developers  who  are  faced  with  those  concern*  typically 
found  in  real-time  embedded  system*.  Descriptions 
art  provided  based  on  responses  to  selected  questions 
from  a  developer’s  survey.  The  authors  followed  the 
thesis  that  each  end  user  must  rank  method*  accord¬ 
ing  to  requirements  that  are  unique  to  that  user,  and 
avoided  making  judgments  on  behalf  of  the  user. 
Several  trends  observed  by  the  authors  are  listed  at 
the  end  of  the  article. 

1.  INTRODUCTION 

The  adoption  and  use  of  methods  represent*  one  of 
the  major  factors  affecting  software  development  dur¬ 
ing  the  past  15  years.  During  this  period,  a  large  vari¬ 
ety  of  methods  has  been  introduced,  and  it  is  natural 
that  attempts  should  be  made  to  compare  these 
methods,  and  to  offer  criteria  by  which  a  software 
development  organisation  can  judge  which  methods  are 
best  suited  to  meet  the  needs  of  the  organisation. 

This  article  demonstrates  a  technique  of  presenting 
information  about  methods  which  forms  a  basis  by 
which  comparisons  can  be  made.  It  is  not  the  inten¬ 
tion  of  the  authors  to  formulate  an  evaluation  of  the 
methods  presented;  rather,  the  article  serves  as  an 
example  of  how  the  software  engineering  community 
can  be  provided  with  information  for  judging  the  suita¬ 
bility  of  a  method  to  the  individual  needs  of  the 
development  organisation. 

The  authors  have  adopted  the  thesis  that  'abso¬ 
lute*  rankings  of  software  development  methods  are 
neither  possible  nor  desirable.  Moreover,  it  is  the 
authors1  position  that  the  needs  of  the  software  devel¬ 
opment  community  are  best  addressed  by  providing 


information  that  can  help  members  of  the  community 
make  their  own  determination  of  how  cWsely  a  given 
method  fils  their  needs.  This  fitness  factor  depends 
upon  the  problem  domain  for  which  coftware  is  being 
developed,  upon  the  background  and  needs  of  the 
development  team,  and  upon  the  environment  in 
which  the  software  is  to  be  developed.  This  environ¬ 
ment  encompasses  the  management  style  and  maturity 
level  of  the  organisation,  as  well  as  the  physical  facili¬ 
ties  of  the  development  organisation. 

Thus,  in  order  to  judge  the  suitability  of  a  method 
for  the  needs  of  an  organisation,  information  for 
making  such  judgments  must  be  readily  available.  As 
an  initial  step  in  providing  such  information,  the 
authors  have  worked  during  the  past  two  years  on  the 
development  of  a  catalog  of  software  development 
methods.  In  order  to  provide  a  ready  basis  of  com¬ 
parison,  the  catalog  employs  a  uniform  style  of  presen¬ 
tation  across  all  methods,  as  well  as  a  tabular  format 
to  contrast  methods.  In  this  article,  the  authors  have 
provided  some  examples  of  the  type  of  information 
presented  in  this  catalog. 

».  BACKGROUND 

The  first  edition  of  the  Software  Methodology  Cat¬ 
alog  [Maha87j  was  developed  for,  and  published  by, 
the  US  Army  CECOM  installation  located  at  Ft.  Mon¬ 
mouth,  New  Jersey.  Information  for  this  catalog  was 
Gathered  primarily  by  surveying  method  developers, 
though  some  additional  information  was  solicited  from 
users  of  methods  in  the  software  engineering  commun¬ 
ity.  The  catalog  contains  descriptions  of  47  methods 
and  is  available  through  the  Defense  Technical  Infor¬ 
mation  Center  (DT1C). 

During  1988,  a  continuation  of  the  project  involved 
the  production  of  a  second  edition  of  the  catalog  based 
on  a  revised  version  of  the  developer  survey.  This  edi¬ 
tion,  when  completed,  is  expected  to  contain  informa¬ 
tion  about  more  than  CO  methods.  The  project  also 
included  a  second  task  in  which  guidelines  were 
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proposed  for  approaches  to  the  twk  of  evaluating 
software  development  method*. 

In  the  initial  phases  of  the  1988  project,  an  analysi* 
wa*  made  of  the  result*  of  the  Tint  survey  effort. 

Based  on  thi*  analysis,  an  extensive  revision  wa*  made 
of  the  questionnaire,  with  emphasis  placed  cn  soliciting 
more  specific  information  on  various  method  a*pects. 
Additionally,  an  extensive  ana]y*in  w rt  made  of  the 
attempt  to  gather  data  from  method  user*.  The 
authors  concluded  that  gathering  meaningful  data 
about  individual  method*  from  uteni  requirt*  informa¬ 
tion  about  the  respondent!  themselves,  and  would 
involve  significantly  more  resources  than  were  available 
in  the  project.  Accordingly,  it  wa*  decided  to  use  only 
developer/vendor  information  a*  a  ba«i*  for  the  second 
edition  of  the  catalog.  The  revised  developer  survey 
wa*  diatributed  during  the  months  of  September 
through  November,  1988. 

Using  information  received  from  this  survey  for  six 
of  the  methods,  thi*  paper  present*  a  sampling  of  the 
basis  for  comparison  which  i*  employed  in  the  catalog. 
The  six  methods  selected  are  suited  for  the  develop¬ 
ment  of  real-time,  embedded  systems.  Such  system* 
represent  a  principal  application  area  for  the  Ada  com¬ 
munity,  and  the  method*  are  representative  of  those 
currently  being  u»ed  for  Ada  development.  Included 
are  mature  methods,  a*  well  a*  methods  which  have 
evolved  in  the  last  few  years.  In  addition  to  the 
appropriateness  for  real-time  development,  the  other 
criteria  for  selecting  the  methods  for  this  article  was 
the  availability  of  survey  responses  at  the  time  the 
article  wa*  prepared.  The  reader  i*  cautioned  that  the 
inclusion  of  these  methods  in  thi*  article  does  not  con¬ 
stitute  a  recommendation.  Furthermore,  before  mak¬ 
ing  evaluative  judgments,  it  ia  evident  that  similar 
information  about  other  methods  should  be  reviewed. 

1.  OVERVIEW  or  THE  SIX  METHODS 

In  this  section,  a  brief  overview  is  given  for  each  of 
the  methods  in  order  to  provide  the  reader  with  a  gen¬ 
eral  frame  of  reference. 

3.1  ADM  —  Ada  Development  Method 

The  developer  of  ADM,  Donald  Firesmith,  charac¬ 
terises  this  method  as  recursive;  i.e.,  a*  cycling  through 
small  parts  of  the  design,  code  and  test  activities.  An 
iarly  version  was  used  in  the  development  of  the 
Advanced  Field  Artillery  Tactical  Data  Systems 
(AFATDS)  in  1985.  The  method  has  both  data-flow 
and  object-oriented  foundations  and  deals  with  most 
activities  associated  with  development. 


Important  steps  to  be  followed  include  the  identifi¬ 
cation  of  Assemblies  and  Duilds;  moreover,  there  arc 
step*  dealing  with  the  stalling  and  scheduling  of 
assembly  development.  Subassemblies  of  each  assem¬ 
bly  are  recursively  elaborated  in  the  manner  outlined 
above.  Part  of  thi*  elaboration  process  includes  pro¬ 
ducing  documentation  a*  well  a*  invoking  configuration 
management.  Some  of  the  step*  for  dealing  with  sub¬ 
assemblies  include  storing  their  requirements  in  a 
mcthod-speciiic  library,  developing  method-specific 
diagrams  and  creating  logicat  designs.  Subassembly 
testing  and  integration  are  planned  activities  addressed 
in  the  method. 

S.t  DGDS  --  Distributed  Computing  Design  Sftltm 

The  DCDS  method  ie  a  collection  of  procedures 
and  tool*  intended  to  deal  with  several  phase*  of  the 
software  process,  including  the  representation  of  the 
system,  representing  software  requirements,  design  and 
testing.  Its  principal  developers  are  Mack  Alford  and 
Loyd  Dakcr;  it  wa*  first  used  at  TRW  in  1973. 

The  initial  step  in  the  method  is  definition  of 
system-level  requirements  using  a  method-related 
language  for  that  purpose.  Definable  entities  include 
functions,  their  inputs  and  outputs  and  their  decompo¬ 
sitions  and  allocations  to  hardware  components. 

Beyond  those,  interface  designs,  control  functions  deal¬ 
ing  with  resource  management,  and  fault  tolerance  are 
definable  with  the  language.  A  method-related 
software  requirements  engineering  technique  is 
employed  to  decompose  the  high-level  definitions  to  a 
state-machine  stimulus-response  level. 

Several  additional  method-related  tools  and  tech¬ 
niques  are  used  to  ensure  consistency,  establish  inter¬ 
faces,  develop  modules  and  package  the  implementa¬ 
tion.  In  particular,  there  are  steps  for  dealing  with  dis¬ 
tributed  processing,  concurrency,  scheduling  and  mem¬ 
ory  constraints.  Finally,  there  also  are  tools  and  tech¬ 
niques  for  developing  integration  tests.  Further  infor¬ 
mation  is  available  in  the  bibliographic  references 
|Alfo87)  and  [DCDS87|. 

3.3  MASCOT  --  Modular  Approach  to  Software  Con • 
itruction,  Operation  and  Test 

The  MASCOT  method  deal*  with  concurrency,  dis¬ 
tributive  processing  and  real-time  issues  from  the  onset 
of  the  software  process.  The  method  atso  identifies 
interfaces  and  data  objects  as  part  of  its  approach 
towards  implementation.  It  started  out  in  the  United 
Kingdom  in  1971  at  Malven  and  has  been  upgraded 
several  times;  Ken  Jackson  and  Hugo  Simpson  are  its 
principal  architects. 
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The  starting  point  of  the  method  is  a  'Design  Pro¬ 
posal'  that  identifies  the  major  functional  subsystems 
and  top-level  internal  data  stores.  Toplevcl  units  are 
decomposed  into  lower  level  ones  by  identifying  active, 
passive  and  device  dependent  components.  The  devel¬ 
oping  network  of  units  has  its  components  defined  in 
terms  of  data-flow,  functionality  and  access  interfaces. 
Network  decomposition  ends  when  simple  elements,  i.e. 
those  that  can  be  directly  implemented  in  a  program¬ 
ming  language,  arc  identified.  In  the  process  of  ela¬ 
borating  designs,  MASCOT  employs  several  templates 
that  have  been  devised  to  match  a  variety  of  cir¬ 
cumstances.  The  method  includes  rules  to  be  followed 
to  guarantee  that  the  simple  elements  conform  to  the 
architectural  structure.  There  also  are  aspects  of  the 
method  that  deal  with  testing.  Four  articles  covering 
MASCOT  were  published  in  a  special  issue  of  the 
Sojtvort  Engineering  Journal, May,  1986,  jointly  pub¬ 
lished  in  London  by  IBB  and  DCS.  Additional  infor¬ 
mation  is  available  from  the  Defense  Research  Informa¬ 
tion  Center,  Glasgow,  Scotland. 

3.4  OOA  -  Object  Oriented  Analysts 

In  19S7,  Boeing  Computer  services  initiated  a  pro¬ 
ject  resulting  in  this  method;  Mark  Smith  and  Stephan 
Tokey  are  its  principal  developers.  The  method  was 
first  used  for  the  development  of  a  deliverable  system 
in  1988.  The  method  calls  for  the  specification  of  the 
requirements  of  a  system  in  terms  of  essential  object 
classes.  The  product  of  the  method  is  a  statement  of 
requirements  that  is  intended  to  be  then  input  to  an 
object-oriented  design. 

Three  essential  activities  make  up  OOA: 

1.  Identification  and  Specification  of  Object  Classes 

2.  Specification  of  Object  Communication 

3.  Identification  of  Class  Operations. 

The  method  is  an  extension  of  existing  methods 
which  employ  Information  modeling,  Data-Flow  model¬ 
ing,  and  Finite-State  modeling.  There  is  a  greater 
emphasis  in  the  method  on  object/class  communication 
and  interaction  which  is  represented  in  the  Object 
Class  Operation  model.  A  more  complete  description 
of  the  method  is  available  in  |Smit88j. 

3.5  SEM  —  Sytltm  Engineering  Methodology 

This  method  is  a  collection  of  techniques  for  deal¬ 
ing  with  system  requirements,  developing  specifica¬ 
tions,  developing  prototypes  and  developing  architec¬ 
tural  designs  for  software.  The  principal  developers  of 
SEM  are  Robert  Wallace  and  John  Stockenberg.  The 


method  has  origins  in  Structured  Analysis  and  Design, 
the  Software  Cost  Reduction  (SCR)  project  and  Sys¬ 
tems  Analysis  of  Integrated  Network  Tasks  (SAINT); 
it  was  first  used  in  its  complete  form  in  1981.  Recent 
systems  developed  include  a  Trident  Defensive 
Weapons  System/Control  Subsystem  and  a  SAM  Mis¬ 
sile  simulator. 

System  requirements  are  analysed  using  modeling 
techniques  based  on  the  U.S.A.F.’s  Integrated  Com¬ 
puter-Aided  Manufacturing  Definitional  Methods  and 
Structured  Analysis.  The  SCR  techniques  are  used  to 
analyse  specifications  and  to  develop  the  architectural 
design  of  the  software.  Evaluations  through  simulation 
and  prototyping  are  accomplished  using  SAINT.  SEM 
also  contains  integration  techniques  that  guide  the  user 
in  bringing  together  the  various  product*  and  results. 

A  comprehensive  view  of  the  method  has  been 
presented  in  (Wall87|. 

3.6  STATEMATB 

Visual  formalism*  are  the  basis  for  thb  method 
developed  by  A.  Pnueli  and  D.  Hard  and  first  used  for 
an  avionics  application  in  1983.  The  method  includes 
tools  and  techniques  for  dealing  with  specification, 
design  and  analysis  of  systems.  Additional  capabilities 
include  management  support  tools  and  simulation  for 
testing  designs. 

A  conceptual  model  is  used  to  deal  with  notions, 
entities  and  procedures  that  are  relevant  to  reactive 
system  development;  i.e.  responsive  to  bjth  subsys¬ 
tems  and  environment.  Three  reprecintational  tech¬ 
niques  are  utilised  to  describe  systems: 

1.  Statecharts,  an  extension  of  finite  state  diagrams, 

are  used  to  specify  behavior; 

2.  Activity-charts  are  used  to  specify  system  func¬ 
tionality; 

3.  Module-charts  are  used  to  specify  system  structure. 
Additionally,  there  are  parts  of  the  method  for  con¬ 
ducting  'what  if'  analyses  and  developing  prototypes. 
Further  information  about  tile  method  is  provided  in 
|Hare87j  and  (IIare88). 

4.  SURVEY  QUESTION  RESPONSES 

In  the  survey  used  to  gather  data  for  the  catalog, 
the  authors  solicited  information  about  specific 
features  of  methods  which  can  be  identified  prior  to  a 
method’s  use  in  the  development  process.  Though  not 
as  significant  as  the  effect  that  results  from  the  use  of 
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a  method  during  the  development  effort,  such  feature* 
do  represent  information  which  clearly  describes  the 
method  rather  than  it*  product. 

Accordingly,  typical  of  the  que*tioni  aahed  in  the 
nurvey  were  what  development  ph*#e«  are  addressed 
by  the  method,  what  type  of  programming  practice*, 
analysis  and  review  technique*  are  e« pouted  by  the 
method,  and  what  mode*  of  repre*entation  are  u*ed  by 
the  method.  Other  question*  focused  on  the  apccific 
way*  that  the  method  provide*  assistance  to  the  devel¬ 
oper  in  area*  *uch  a*  error  detection,  incorporation  of 
change,  and  identification  of  reu*able  component*. 
Information  a!*o  war  nought  regarding  automated  sup- 
port  provided  with  the  method,  available  training,  and 
public  ally  available  bibliographic  reference*  about  the 
method.  In  addition,  the  opinion  of  each  developer 
waa  aolicited  concerning  the  amount  of  time,  and  the 
type  of  background  needed  to  learn  the  method. 

In  the  vcction*  which  follow,  a  (election  of  theie 
que*tiona  are  presented  along  with  the  rc*pon*e« 
received  for  the  tix  method*. 

4.1  Techniques  Employed  Ay  Me  Method 

In  an  effort  to  learn  the  degree  of  importance  of 
well-known  programming  concept*  and  practice*  to 
proper  u*e  of  the  method,  the  respondent*  were  aaked 
to  describe  the  extent  to  which  certain  concepts  and 
practice*  were  u*ed  in  the  method.  In  Table  1,  below, 
the  response*  are  coded  aa:  E  for  essential,  Cfor  com- 
patible,  and  U for  unknown  relationship  to  the  method. 
No  respondent*  answered  that  the  listed  practice*  were 
incomistent  with  their  respective  methods. 


TABLE  1  -  Use  of  Programming  Practices. 


METHOD 

Coneepli 

H 

D 

M 

El 

and 

n 

C 

A 

o 

rrnetke* 

M 

D 

S 

El 

M 

S 

C 

■ 

Stepwise  Refinement 

11 

b 

m 

m 

m 

lafoemallo*  Hiding 

□ 

13 

B 

B 

B 

Process  Abstraction 

B 

li 

B 

B 

B 

Abstract  Datn-type* 

D 

D 

o 

B 

B 

Structured  Programming 

□ 

13 

B 

B 

B 

Cenerkity 

K3 

D 

B 

B 

B 

Inheritance 

b 

u 

B 

B 

B 

Use  ot  assertions 

□ 

S3 

S3 

B 

B 

Module  coupling/cohesion 

D 

B 

B 

B 

B 

In  an  effort  to  learn  what  analysis  and  review  tech¬ 
niques  were  essential  to  using  the  method,  the  respon¬ 
dents  were  asked  to  describe  the  extent  to  which  each 
of  certain  well-known  techniques  were  used  in  the 
method.  The  responses  were  to  be  coded  with  P.  for 
required,  E for  encouraged,  and  Affor  nof  addressed  by 
the  method.  Table  2,  below,  shows  the  response* 
obtained  to  this  question. 


TABLE  1  -  Use  of  Analysis  and  Review  Technique*. 


METHOD 

Analysis  and 

A 

D 

St 

0 

S 

S 

Review  Technique* 

D 

C 

A 

0 

E 

T 

M 

D 

S 

A 

M 

M 

S 

C 

T 

Daln-itructured  analysis 

N 

■Jr 

N 

R 

T 

"h* 

Data-flow  analysts 

R 

R 

R 

R 

R 

F. 

Coulrobflow  analysis 

R 

R 

E 

R 

R 

E 

Decision  table* 

N 

E 

F. 

E 

R 

N 

Formal  proof  technique* 

N 

N 

N 

N 

N 

E 

Design  rcvkws 

R 

R 

R 

E 

E 

E 

Code  walk-throughs 

R 

R 

E 

N 

N 

N 

Change  control  revkw 

R 

E 

E 

N 

N 

N 

4-t  Technology  Transfer  Issues 

Another  series  of  questions  aaked  the  respondent* 
to  estimate  certain  learning  times,  such  as  the  time 
required  to  attain  a  high-level  of  understanding.  It  is 
also  important  to  know  how  long  it  will  take  to  learn 
enough  to  make  reasonable  use  of  a  method  and  how 
long  it  might  take  to  become  an  expert.  The  results 
obtained  are  summarised  in  Table  3. 


TABLE  3  -  Learning  Times  for  Methods. 


ia 

METHOD 

Estimated 

D 

D 

M 

□ 

s 

s 

Learning 

D 

C 

A 

El 

E 

T 

Time* 

M 

D 

S 

D 

M 

S 

C 

■ 

Dtps  • 

prefect  manager 
overview 

H 

H 

~T 

T 

2 

1 

Dtft  • 

experienced  developer 
learning  essentials 

H 

5 

S 

s 

10 

2 

Months 

-  to  become 

3 

2 

2 

« 

2-4 

3 

an  expert  user 

Developers  of  software  development  methods 
assume,  perhaps  implicitly,  that  the  users  of  their 
methods  are  capable  of  understanding  and  following 
the  instructions  given.  Consequently,  one  type  of 
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precondition  for  proper  u*«  of  any  method  is  the  set  of 
assumptions  made  about  the  method  user's  education 
and  experience.  The  queetionnaire  poeed  several  ques¬ 
tion*  about  these  precondition*;  queition*  about  tech¬ 
nical  or  college-level  education  a*  well  a«  about  experi¬ 
ence  with  programming  language*  and  in  previou* 
development  situation,*.  In  Table  4,  the  result*  are 
tummariaed;  note  that  OOA  i*  omitted  because  no 
answer*  were  provided  by  the  respondent. 


TABU  4  -  Minimum  Education  and  Experience. 


METHOD 

Minimum 

A 

D 

M 

s 

S 

Qualification* 

D 

C 

A 

E 

T 

M 

D 

S 

M 

M 

S 

C 

T 

Cottet*.  level 

4 

4 

tM 

4 

i— -  i 

4 

technical  education 

Number  at  yean  at 

1-2 

J-S 

1-2 

J-S 

~Q~ 

development  experience 

Number  et  prof.  laaf. 

I 

1 

1 

1 

(worhlnf  kno«led|r) 

Number  of  nyrletm  with 

1 

5-4 

2 

1 

1 

which  one  haa  experience 

Final'y,  it  i*  useful  to  know  the  type  of  theoretical 
background  which  is  expected  of  the  developer  in  order 
that  he  or  she  can  learn  to  use  the  method.  The  sur¬ 
vey  attempted  to  identify  the  necessary  theoretic  con¬ 
cepts  in  the  question  which  follows. 

Question:  List  the  rn^Jor  theoretical  construet(s) 
which  should  be  understood  by  an  experienced 
developer  in  order  to  successfully  use  the  method. 

The  responses  of  the  developers  are  summarised  below. 

ADM  Abstract  state  machines,  abstract  data 

types,  object  abstraction,  process  recursion, 
and  knowledge  of  the  Ada  language. 

DGDS  F_NETS  (control-flow  structure),  and 

R_NETS  (stimulus-response  thread  structure). 

MASG  Concepts  of  asynchronous  concurrency,  and 
data-flow  analysis. 

OOA  Entity-Relationship-Attribute  Modeling, 
data-flow  diagrams,  finite-state  machines, 
object  classes. 


SIM  The  concepts  which  are  typically  found  in  an 
undergraduate  computer  science  program. 

STMT  State  machine  knowledge. 

I.  ADDITIONAL  RESPONSES 

The  survey  also  contained  a  series  of  questions 
designed  to  provide  brief,  but  specific,  information  rel¬ 
ative  to  certain  features  of  method*.  The  questions 
focused  on  key  issues  such  as  client  involvement, 
mode*  of  representation,  reusability,  and  assistance 
provided  by  the  method  relative  to  certain  aspects  of 
the  development  process.  In  the  sections  which  follow, 
a  sampling  of  these  questions  is  provided,  along  with  a 
paraphrasing  of  the  responses  provided  for  each  of  the 
method*. 

For  each  section,  a  brief  rationale  is  given  for  inclu¬ 
sion  of  the  question  in  the  survey.  No  comments,  how¬ 
ever,  are  offered  on  the  substance  of  the  response*.  It 
is  the  authors’  belief  that  the  reader  is  best  able  to 
judge  the  appropriateness  of  the  responses  based  upon 
his  or  her  own  experience  in  developing  systems.  Note 
that  where  response*  are  missing,  information  was  not 
provided;  further  investigation-  is  necessary  to  clarify 
these  areas.  The  authors  caution  that  the  reader 
should  avoid  drawing  any  negative  inference  in  the  sit¬ 
uation  where  no  response  is  reported. 

5.1  Client  Involvement 

A  key  component  in  the  use  of  a  method  involves 
what  aspects  of  the  method  assist  in  communicating 
with  the  client,  and  where  the  method  requires  the 
involvement  of  the  client.  Two  questions  dealing  with 
this  issue  were  included  in  the  survey. 

Question:  What  specific  features  or  aspects  of  the 
method  are  designed  to  facilitate  and  coordinate  com¬ 
munication  between  the  client  and  the  development 
organisation? 

ADM  Communication  is  facilitated  through  the  use 
of  graphics,  and  a  verb/direct  object  program 
design  language.  The  method’s  close  relationship  to 
the  Ada  language  also  facilitates  communication  for 
implementations  which  axe  Ada-based. 

DCDS  The  method  employs  English-like  languages 
to  describe  elements,  relations  and  attributes. 
Extensive  graphics  are  also  used,  and  automated  docu¬ 
ment  generation  is  provided. 
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MASC  The  method  specifically  require*  that  the 

developer  identify  required  function*  and  the 
required  interaction*  with  the  environment.  The 
de«i|n  technique  need  enable*  traceability  to  be  e«ta- 
bli*hed  back  to  thete  item*. 

OOA  The  *everal  model*  used  represent  the  »y*tem 
from  several  perspective*  and  at  various  level* 
of  detail.  The  representation*  employed  are  highly 
graphical,  precise,  and  unambiguous. 

SEM  The  method  employ*  client-oriented,  high- 
level  de*cription  technique*  (data-flow, 
control-flow,  and  information  modeling)  to  ca«e  client 
review.  The  method  al*o  provide*  traceability  of 
requirements  to  the  final  product. 

STMT  Decause  the  system  specification*  can  be  exe¬ 
cuted  and  prototyped,  the  development  team 
can  demonstrate  proof  of  analysis  concepts  in  an 
animated  execution  or  prototyped  form.  Furthermore, 
at  any  stage  of  project  development,  the  method's  pro¬ 
totype  module  can  generate  code  from  the  specifica¬ 
tion*  which  can  be  run  in  the  target  environment,  thus 
allowing  for  further  evaluation  by  both  developer  and 
client. 

Question:  Specifically,  what  procedure*  does  the 
method  provide  for  Involving  the  client  during  the 
software  development  process,  and  where  doe*  this 
involvement  occur? 

ADM  Dy  being  recursive  (sic}  and  developing  the 

design  and  the  code  early,  it  provides  many  of 
the  benefit*  of  rapid  prototyping  without  the  disadvan¬ 
tage*.  Since  the  design  is  compilable,  the  client  is  able 
to  review  a  tested  design  rather  than  mere  paper 
design. 

DGDS  Automatic  facilities  are  provided  for  pro¬ 
ducing  documents  for  System  Requirements 
Review,  for  System  Design  Review,  and  for  the 
Software  Specification  Review.  Additionally,  prelim¬ 
inary  Kid  detailed  versions  of  the  SDD  are  produced 
for  the  Preliminary  Design  Review  and  the  Critical 
Design  Review.  The  method  also  supports  the  produc¬ 
tion  of  test  reports  for  the  Functional  Configuration 
Audit  and  the  Physical  Configuration  Audit. 

MASC  The  client  is  involved  in  'signing  off*  the 
required  functions  and  interactions  at  the 
beginning  of  the  design  stage.  Additionally,  the  client 
must  approve  the  acceptance  test  procedures. 


OOA  The  method  require*  interview*  with  the 
client  during  the  requirements  gathering 
stag<-  The  client  also  participate*  in  the  OOA  docu¬ 
ment  walkthroughs. 

SEM  The  high-level  graphical  language  used  at 

the  front  end  of  system  development  is  specif¬ 
ically  designed  to  facilitate  client  review,  and  even 
enable  client  participation  in  system  definition. 

STMT  At  any  phase  in  development,  the  client  i* 
able  to  review  the  executable  specification* 
and/or  the  prototype  code  which  i*  provided  by  the 
method. 

S.t  Modes  of  Representation 

Central  to  the  use  of  a  method  are  the  mode*  of 
representation  selected  by  the  method  to  describe  the 
evolving  system.  Providing  a  variety  of  modes  of 
representation  enhance*  the  ability  of  the  developer  to 
analyse  the  system,  and  facilitate*  communication 
among  the  technical  team,  management,  and  the 
client.  On  the  other  hand,  a  key  to  the  use  of  multiple 
representations  is  the  ability  to  translate  from  one 
mode  to  another. 

Qutstiom  Use  of  what  modes  of  representation, 
either  textual  or  iconographical,  are  required  or 
strongly  encouraged  by  the  method? 

ADM  The  method  requires  the  use  of  Petri  nets, 
data-flow  diagrams,  conlrol-fiow  diagrams, 
hierarchy  charts,  Buhr  diagrams,  Fircsmith  diagrams, 
and  a  program  design  language.  Use  of  finite-state 
diagrams  and  a  formal  specification  language  is 
strongly  encouraged  by  the  method. 

DCDS  The  method  requires  the  use  of  control-flow 
diagrams,  flowcharts,  narrative  overviews  of 
modules,  a  formal  specification  language,  and  specified 
documentation  templates.  The  method  strongly 
encourages,  and  provides  automated  support  for,  the 
use  of  data-flow  diagrams,  entity-relationship  dia¬ 
grams,  decision  tables,  and  a  program  design  language. 

MASC  The  method  requires  the  use  of  a  narrative 

overview  of  modules,  data-flow  diagrams,  and 
hierarchy  charts  and  other  diagrams  specific  to  the 
method.  The  use  of  finite-state  diagrams,  a  program 
design  language,  structured  English  and  specified  docu¬ 
mentation  templates  is  strongly  encouraged  by  the 
method. 
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OOA  The  method  strongly  encourage*  the  use  of 
finite-state  diagram*,  data-flow  diagram*, 
entity-relalion»hip  diagram*,  object  communication 
diagram*,  and  object  operation  diagram*. 

SEM  The  method  require*  the  u*e  of  data-flow 
diagram*,  control-flow  diagram*,  entlty- 
relationthip  diagram*,  decision  table*,  mathematical 
notation,  and  vpecified  documentation  template*. 
Additionally,  the  u*c  of  Petri  net*  i*  itrongly 
encouraged. 

STMT  The  method  require*  the  u*e  of  finite-state 
diagram*,  atatechart*,  activity-chart*  which 
arc  *imilar  to  data-flow  diagram*,  and  module  chart* 
to  *how  structure.  The  method  strongly  encourage* 
the  use  of  a  formal  specification  language  and  specified 
documentation  template*. 

Question:  If  the  method  use*  several  mode*  of  expres¬ 
sion,  identify  the  ca«c«  la  which  *  mapping  rule  U 
prescribed  whleh  enable*  translating  from  one  mode  to 
another. 

ADM  1)  Data/control  flow  diagram*  -*  tubas- 
terribly  object-oriented  design  diagrams; 

2)  object  diagrams  -♦  data/controi  flow  diagram*. 

DCDS  1)  F_Net  (control  flow)  and  text  database 
information  -♦  IDEFo  diagram  (data-flow); 

2)  Logic  flow  diagram  -*  a  PDL;  3)  Extended  ERA 
graphic*  — *  HIPO  chart*. 

OOA  Guidelines  are  provided  for  mapping  entity- 
relationship  diagram*  into  Booch  and  Buhr 
diagram*. 

SEM  Data-flow  diagram*  — *  Petri  net*; 

2)  data-flow  diagram*  -♦  control-flow 
diagram*;  3)  data-flow  and  control-flow  diagram*  — ♦ 
Template  Baaed  Specification*. 

STMT  1)  Activitie*  -♦  module*;  2)  module*  -*  act¬ 
ivities  charts;  3)  control  activities  within  the 
activities  charts  -*  statecharts. 

S.S  Transformation  Across  Phases 

In  the  two  questions  which  follow,  information  is 
solicited  as  to  how  the  method  assists  in  moving  from 
one  phase  cf  software  development  to  the  next,  and 
what  features  in  the  method  assist  the  developer  in 
maintaining  consistency  &.,iong  specification,  design, 
and  code. 


Question:  Specifically,  bow  does  the  method  facilitate 
the  transformation  aero**  phase*  of  the  software  pro¬ 
cess?  (For  example,  from  specification  to  design,  or 
from  design  to  codt.) 

ADM  The  method  u*e*  object-oriented  data-flow 

diagram*  which  lead  naturally  to  subassembly 
OOD  diagram*.  The  Ada-oriented  graphic*  and  com¬ 
pilable  PDL  facilitate  the  transformation  from  design 
to  code. 

DCDS  Transformation  aero**  phases  is  partially 

automated.  Upon  completion  of  the  system 
requirement*  database,  the  clement*  to  be  forwarded 
are  automatically  written  to  a  file.  When  the  software 
requirement*  database  is  opened,  this  flic  provides  the 
information  whereby  the  element*  from  upstream  can 
be  transformed  into  clement*  of  the  downstream 
language.  The  same  process  is  repeated  when  opening 
the  distributed  design  phase,  the  module  development 
phase,  and  the  test  phase.  The  languages  provided  for 
each  phase  are  similar,  though  specific  to  the  phase. 

MASC  The  method  achieves  coherence  between  the 
design  architecture  and  the  implementation 
architecture  by  making  them  identical.  Thus,  no 
transformation  is  required. 

OOA  Object-classes  which  are  identified  through 
use  of  the  method  should  map  logically  onto 
design  classes,  and  these  in  turn  should  map  in  a  one- 
one  manner  onto  source  code  object  classes,  such  as 
Ada  packages. 

SEM  Detailed  procedures  are  provided  by  the 
method  which  provide  for  transformations 
from  each  representation  to  the  next. 

STMT  Transformation  across  phases  is  facilitated 
by  supporting  several  conceptual  levels  with 
the  use  of  the  same  model.  The  method  provides  the 
reports,  executable  models,  related  databases,  and  test 
suites  to  support  this  common  model. 

Question:  Specifically,  how  does  the  method  assist  in 
ensuring  that  consistency  is  maintained  among  specifi¬ 
cation,  design,  or  code  when  changes  are  made  to  any 
of  these  three  entities? 

ADM  Maintaining  consistency  of  requirements  and 
design  is  facilitated  because  the  method  uses 
object-oriented  data-flow  diagrams  which  lead  natur¬ 
ally  into  the  subassembly  object-oriented  diagrams  of 
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the  d**ign.  Consistency  of  de*ign  and  code  i*  main¬ 
tained  through  the  km  of  Ada-oriented  graphic*  and  a 
compilable  program  d«*!gn  language  which  evolve*  into 
th«  deliverable  code, 

DCDS  Tht  method  ha*  role*  and  construct*  for  eie- 
menu,  relation*,  and  attribute*  which  a**i«t 
in  maintaining  traceability  from  requirement*  to 
design,  and  from  de«ign  to  both  codt  and  te*t*. 

MASC  Tht  method  guarantee*  total  consistency 

between  the  dc*ign  itructure  and  the  imple¬ 
mentation  structure.  Incon*i*lency  cannot  be  intro¬ 
duced  by  implementor*  *ince  any  change  mu*t  be 
introduced  at  the  deeign  level  and  then  propagated 
into  the  implementation. 

SKM  AU  pha*e*  of  development  thare  a  common 
semantic  ba*e,  and  thu*  traceability  i*  built 
into  the  development  proce**.  There  i*  never  any 
ambiguity  which  will  ari*e  in  tracing  from  high-level 
requirement*  to  (pacification*  and  dc«ign. 

STMT  The  method  eniure*  conaiatency  through  the 
u*c  of  teat  Kenario*.  Teat  re«ult«  are  defined 
and  achieved  at  different  phaae*  in  the  development 
proce**. 

S.4  Oiktr  Development  luuti 

In  this  laat  section,  reaponae*  are  preaented  for 
queationa  which  deal  with  the  a*«i*tance  provided  by 
the  method  for  the  following: 

1.  Early  detection  of  error*  and  inconaiatenciea; 

2.  Incorporation  of  change*  in  requirement*; 

3.  Addressing  tuning  conatrainti  and  concurrency; 

4.  Identification  of  reuaable  component*. 

Question:  Specifically,  how  doe*  the  method  asalat  In 
the  early  detection  of  inconaiatenciea  and/or  errortT 

ADM  By  employing  a  recuraive  (aic)  technique  of 

'deeign  a  little,  code  a  little,  teat  a  little',  the 
method  producea  early  compilable  deaigna  and  early 
teated  code. 

DCDS  The  method  providea  automated  facilitiea  for 
checking  completeneaa  and  conaiatency.  A 
check  ia  provided  for  uae  at  the  end  of  every  major 
step. 


MASC  The  complete  design  architecture  i*  checked 
for  *elf-con(i*tency  by  a  procedure  known  a* 
'statu*  progression*.  Thi*  procedure  ensure*  that  the 
design  structure  i«  sound  before  implementation  i* 
undertaken.  A  system  can  only  achieve  fully-checked 
status  when  all  module*  upon  which  the  system 
depends  have  them*clve*  achieved  a  similar  statu*. 

OOA  Rules  are  provided  for  establishing  the  con¬ 
sistency  among  the  entity-relationship  model, 
the  finite-state  model,  the  data-flow  diagram*,  the 
object  interaction/communicaticn  diagram*,  a^d  the 
object  operation  model  (modified  Booch  diagram*). 

SEM  The  method  provide*  a  simple,  easily  under¬ 
stood  graphical  language  for  defining  system 
functions  and  behavior.  The  method  also  employ*  a 
built-in  review  procedure,  and  the  uae  of  simulation  for 
dynamic  feedback. 

STMT  The  method  provide*  a  mechanism  whereby  a 
model  of  the  system  can  be  created,  syntacti¬ 
cally  analysed,  executed,  dynamically  teated,  proto¬ 
typed,  and  debugged. 

Question:  Specifically,  bow  doe*  tbe  method  ***l*t  fat 
reducing  tbe  effort  needed  to  fiilly  Incorporate  change* 
la  the  requirement*! 

ADM  As  an  object-oriented  approach,  the  method 
produce*  software  that  ia  more  extensible 
because  changes  to  requirements  are  better  localised  in 
the  design  due  to  a  lower  level  of  data  coupling. 

DCDS  Two  element  types  are  provided  for  assisting 
in  incorporating  change.  The  element  type 
CHANGE_REQUEST  is  used  for  formal  change*  in 
baselined  requirements.  The  element  type  DECISION 
is  used  for  refinements  that  arise  during  development. 

MASC  The  impact  of  changes  can  easily  be  traced 
to  the  affected  areas  of  the  design.  Tho 
method's  emphasis  on  well-defined  interfaces  and  on 
the  general  architectural  features  yields  a  high  level  of 
decoupling  within  the  design,  thus  limiting  the  effect  of 
change. 

OOA  The  method  employs  a  partitioning  of  the 
requirements  based  upon  object-classes. 
Requirements  are  stated  exactly  once,  and  are  parti¬ 
tioned  around  other  closely  related  requirements. 
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SEM  The  method'*  use  of  separation  of  concern* 
and  level*  of  granularity  ensure  that  for  each 
proposed  *y*tem  change,  there  is  only  one  place  in  the 
statement  of  requirement*  where  the  change  need*  io 
lx  incor|>orated.  The  ripple  effect  i*  avoided. 

Question:  What  specific  aipect*  of  the  method 
addre**  requirement*  of  the  target  tyitcm  which 
involve  tinting  constraint*  and/or  concurrency  i*«ue«? 

ADM  The  method  u«e«  timing  diagram*,  and 

employ*  Petri  net*,  Duhr  diagram*,  and  a 
ta*k  fequencing  language  to  address  concurrency 
issue*. 

DCDS  For  the  *oftware  requirement*,  the  method 

require*  that  completion  condition*  and  delay 
event*  he  addrc**cd.  During  *oftware  design,  timing 
constraint*  arc  specified  for  each  routine.  A**i*tance  is 
provided  for  addressing  concurrency  through  a  full  *et 
of  language  constructs,  and  the  availability  of  an  ana¬ 
lytical  tool. 

MASC  Timing  constraints  are  addressed  in  the 
behavioral  model  which  encompasses  con¬ 
currency,  process  synchronisation,  and  deterministic 
scheduling.  The  design  representation  specifically  dis¬ 
tinguishes  between  concurrent  (active)  processes  and 
passive  data-objects. 

OOA  Concurrency  is  addressed  by  the  fact  that 
each  instance  of  an  object  class  a  allowed  to 
exist  at  any  point  in  its  behavioral  lifecycle. 

SEM  Timing  and  resource  constraints  are  analysed 
through  the  use  of  control-flow  (behavior) 
models.  Simulation  is  used  to  further  analyse  system 
timing,  concurrency  issues,  and  resource  contention. 

STMT  Timing  constraints  and  concurrency  issues 
are  incorporated  in  the  statechart  modeling, 
and  can  be  dynamically  tested. 

Note  that  a  question  involving  spatial  constraints  was 
also  asked  on  the  survey.  Unfortunately,  the  set  of 
answers  provided  for  the  question  were  generally  unin¬ 
formative.  In  the  authors’  opinion,  this  might  be 
explained  by  the  tendency  of  software  development 
methods  to  give  too  much  of  a  'black-box*  view  to 
those  concerns  which  involve  hardware. 


Question:  Specifically,  how  doe*  the  method  assist  In 
identifying  possible  reusable  component*  such  a* 
design  or  code? 

ADM  The  method  ha*  an  vlditional  *tep  in  the 
design  decision  proces*  where  the  issue  of 
reuse  i*  addressed.  Reusable  candidates  naturally 
occur  since  the  default  packages  implement  abstract 
data  type*  and  abstract  state  machine*. 

DCDS  The  module  development  procedure  provides 
guidelines  for  selecting  module*  which  should 
be  kept  in  the  reusability  library.  Thi*  procedure  also 
assists  the  developer  in  setting  up  and  maintaining  a 
reusability  library  using  DCDS  tool*. 

MASC  The  design  architecture  is  predicated  on  the 
concept  that  all  components  are  derived  from 
template*.  Thus,  all  template*  are  by  their  nature 
reusable,  and  are  always  specified  in  term*  of  ihe 
access  interface*  that  they  provide  or  require. 

SEM  Emphasis  on  the  ure  of  separation  of  con¬ 
cern*  and  of  information  hiding  assists  in 
developing  reusable  specification  and  design  com¬ 
ponents. 

STMT  The  method  encourages  the  identification  of 
units  that  can  be  treated  as  reusable  com¬ 
ponent*. 

w.  onsiiiiv  ’AT5GNS  AND  CONCLUSIONS 

In  the  authors’  opinion,  there  are  several  interest¬ 
ing  trends  which  can  be  observed  from  the  data  pre¬ 
sented.  These  include: 

•  The  minimum  qualifications  generally  needed  by 
developers  to  use  these  methods  includes  a  four- 
year  undergradaute  technical  education  and  from 
one  to  five  years  of  development  experience. 

•  The  use  of  data.flow  analysis  and  finite  state 
machines  are  central  to  these  real-time  methods. 

•  Iconographical  representations  are  extensively  used 
by  these  methods. 

•  Multiple  representations  of  the  evolving  system  are 
frequently  employed,  and  the  methods  recognise 
the  importance  of  providing  rules  or  guidelines  for 
mapping  from  one  representation  to  another. 
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•  While  reusability  U  viewed  a*  an  important  issue, 
specific  rule*  for  creating  and/or  identifying  reus¬ 
able  component*  have  not  been  completely 
addressed. 

•  Use  of  «*rrlion*  and  format  proof  technique*  are 
not  currently  an  integral  part  of  these  method*. 

It  would  be  interesting  to  learn  whether  the  «*me 
trend*  can  lie  observed  for  other  real-time  development 
method*. 

IJascd  on  their  experience  with  thi*  project,  the 
author*  conclude  that  hard  real-time  requirement* 
have  been  addressed  more  fully  by  method*  than  spa¬ 
tial  constraint*  associated  with  embedded  system*. 
Finally,  the  author*  remain  convinced  that  the  use  of  a 
uniform  format  for  presenting  information  about 
method*  provide*  a  bast*  by  which  individual  develop¬ 
er*  and  organisations  can  judge  what  methods  best 
suit  their  need*. 
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TECHNIQUES  FOR  OPTIMIZING  ADA/ASSEHBLY  LANGUAGE  PROGRAM  INTERFACES 
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Computer  Sciences  Corporation 


Abstract. 

Thin  paper  describes  several  techniques 
for  interfacing  assembly  language  routines 
to  Ada  programs.  These  techniques  exhibit 
varying  degrees  of  complexity,  maintain¬ 
ability,  and  performance.  The  basic  op¬ 
tions  and  mechanics  involved  in  establish¬ 
ing  the  interface  between  an  Ada  and 
assembly  language  program  will  be  dis¬ 
cussed.  The  ASMQG  assembly  language  will 
be  used  for  example  purposes,  although  the 
interfacing  techniques  will  bo  presented 
in  a  generalised  fashion  so  that  readers 
from  a  broad  spectrum  of  assembly  language 
product  backgrounds  may  benefit.  Increas¬ 
ingly  sophisticated  techniques  for  opti¬ 
mising  performance  will  then  be  given, 
benchmark  teat  results  will  highlight  the 
trade-offs  between  program  maintainability 
and  performance  efficiency.  Special  o»- 
phasls  will  bo  given  to  the  parameter 
passing  mechanism.  The  paper  concludes 
with  a  set  of  guidelines  for  managing  the 
Implementation  of  Ada/assembly  language 
program  Interfaces. 


Background. 

There  are  a  number  of  reasons  why  the 
ability  to  interface  lower  level  programs 
to  an  Ada  program  is  important.  A  primary 
reason  is  simply  to  enable  access  to  lower 
level  machine  capabilities.  Another  Im¬ 
portant  reason  is  to  improve  program  per¬ 
formance  characteristics  of  certain  speed 
critical  program  operations.  The  primary 
focus  of  this  paper  will  be  directed  to¬ 
wards  the  latter  concern. 

The  Interfacing  techniques  described  in 
this  paper  were  developed  during  a  re¬ 
search  effort  to  analyze  the  possible  Ada 
conversion  of  a  major  DoD  weapon  system 
employing  fiber  optic  technology.  High¬ 
lights  of  the  results  of  this  research 
were  reported  by  the  author  at  the  Sixth 
National  Conference  on  Ada  Technology  in  a 
paper  entitled  "Research  on  the  Ada  Con¬ 
version  of  a  Distributed,  Fast  Control 
Loop  System".  This  paper  identified  and 
explained  how  several  performance  critical 
areas  of  the  existing  gunner  station 


software  were  converted  from  PL/M-8G  to 
Ada  and  then  benchmark  tested.  The  bench¬ 
mark  test  results  were  analyzed,  and  a 
Hat  of  compiler  characteristics  critical 
to  a  successful  Ada  conversion  was  devel¬ 
oped  -  characteristics  both  within  snd  be¬ 
yond  tho  current  Ada  language  standard. 
Assembly  language  program  Interfaces  were 
mentioned  in  this  paper  as  a  means  to  ob- 
tain  access  to  vital  lower  levol  machine 
facilities  auch  as  the  shared  resource 
synchronisation  mechanism,  and  to  improvo 
the  execution  speed  of  performance  sensi¬ 
tive  areas.  Thia  paper  extends  the  re¬ 
search  results  of  the  original  paper  by 
examining  in  detail  tho  assembly  language 
program  interfacing  techniques  used. 


Why  assembly  language  interfaces  are  im¬ 
portant. 

Higher  ordor  languages  allow  us  to  work  at 
more  abstract  levels  than  do  more 
primitive  machine  level  languages.  This 
is  vital  to  software  developers  for  obvi¬ 
ous  reasons.  Working  at  a  higher  levol  of 
abstraction  results  In  substantially  in¬ 
creased  development  productivity  and  en¬ 
hanced  ability  to  create  understandable 
and  maintainable  programs. 

Embedded  computer  systems,  particularly 
thoso  found  in  advanced  weapons  systems, 
present  special  challenges  for  software 
engineers.  Such  systems  often  require  in¬ 
terfaces  to  numerous  external  devices  or 
other  external  systems,  and  these  intar- 
faces  -tre  often  of  a  specialized  or  non- 
standard  nature.  Raw  processing  power  and 
memory  size  are  often  severely  constrained 
because  of  tho  physical  environment  Jr 
which  the  embedded  computer  system  must 
operate.  As  a  result,  programming  effi¬ 
ciency  can  become  very  critical. 

Because  of  the  special  environmental  fac¬ 
tors  found  in  embedded  computer  systems, 
ac.ess  to  machine  dependent  features  is 
Important  fur  two  reasons.  One  reason  is 
to  support  efficient  external  interfaces, 
the  other  is  to  iuprove  the  execution 
speed  of  the  application  software. 
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The  Ad*  representation  specifications  are 
the  vehicle*  for  permitting  us  to 
reference  low  level  feature*  with  Ad*  con¬ 
struct*  that  are  used  at  a  higher,  more 
abstract  level.  These  higher  level  con¬ 
structs  or  entitles  are  uted  In  high  level 
solution*  at  high  levels  of  abstraction. 
Representation  specifications  allow  us  to 
Map  those  high  level  construct*  to  the  un¬ 
derlying  machine. 

In  soma  tine  critical  applications,  an  ap¬ 
proach  using  Ada  codo  only  may  fail  to 
meet  performance  requirements.  Sometimes 
a  resort  to  assembly  language  code  Is  the 
only  means  available  to  improve  system 
performance  to  acceptable  levels.  Fur¬ 
thermore,  some  embedded  system*  applica¬ 
tion*  require  access  to  special  machine 
dependant  features  which  may  simply  be  un¬ 
available  through  high  level  Ada  con¬ 
structs  and  programming  facilities,  and 
these  machine  lev*,  features  may  be  abso¬ 
lutely  indispensable  for  the  application 
to  perform  its.  Intended  function.  This  is 
especially  true  with  Ada  compilers  which 
lack  the  full  range  of  Chapter  13  fa¬ 
cilities.  For  example,  consider  on  embed¬ 
ded  application  with  multiple  central  pro¬ 
cessing  units  that  execute  processes  which 
communicate  with  one  another  through  data 
structures  in  shared  memory  over  t>  shared 
system  bus.  The  prsgma  SHARED  specifies 
that  a  read  or  write  operation  on  a  shared 
variable  must  be  Implemented  as  an  indi¬ 
visible  operation.  This  pragma  enables  a 
variable  shared  by  different  concurrently 
running  processes  to  be  accessod  and  up¬ 
dated  by  those  processes  without  risk  of 
corruption  due  to  aiaultaneous  access .  If 
the  Ad*  compiler  used  in  generating  the 
applications  software  dees  not  support  the 
pragma  SHARED,  then  a  resort  to  a  lower 
levol  machine  lcnguage  is  the  only  moans 
to  implement  a  shared  data  structure. 

Ada  provisos  the  Jneans  to  write  low  level 
machine  statements  without  stepping  out¬ 
side  cf  the  language  itself  through  the 
u.«e  of  representation  spocif  icatlons. 
This  is  ideally  dona  by  creating  a  package 
that  exports  a  record  abstracting  the 
processor's  instruction  set  mnemonics. 
Accoss  to  low  levc.i  machine  facilities  is 
also  possible  through  pragma  IHTERFACE. 
The  arguments  for  thic  pragma  are  a  sub¬ 
program  name  and  the  name  of  the  language 
(ouch  as  an  assembly  language)  in  which 
the  subprogram  was  written.  Pragma  IHTER¬ 
FACE  therefore  is  used  to  specify  to  an 
Ada  compiler  that  an  object  module  built 
in  anothe-  language  is  to  bo  incorporated 
for  seat  specified  subprogram.  This  ap¬ 
proach  involves  stepping  outside  of  che 
Ada  language  itself,  and  is  obviously  1033 
dnu’rablo  thru  the  full  Ado  lovol  approach 
o*  abstracting  the  processor's  instruction 
set.  dill!,  with  some  Ad&  compilers  this 


approach  may  be  the  only  avenue  available 
to  capitalise  on  benefits  obtainable  from 
low  level  machine  features.  With  some 
time  critical  applications,  this  may  mean 
the  difference  between  meeting  and  not 
meeting  performance  requirements. 


Motivation  for  technique  development. 

A  highly  time  critical  module  in  the 
PL/H-86  based  gunner  station  software  in¬ 
terfaces  with  an  sutotracker.  Sixty  times 
a  second,  this  device  Interrupts  the  epu 
to  provide  s  value  for  the  missile  posi¬ 
tional  error  with  respect  to  a  moving  tar¬ 
get  on  which  the  autotracker  Is  fixed. 
Also,  sixty  times  a  second,  this  error 
value  must  be  procesr*'*  ,y  the  digital 
autopilot  software  running  on  a  different 
cpu.  The  digital  autopilot  program  uses 
this  error  value  to  derive  a  fin  movement 
command.  The  fin  command  generated  is  de¬ 
signed  to  move  the  missile  so  that  future 
error  signals  will  be  nulled. 

It  Is  obvious  that  this  application  is 
time  critical.  The  program  which  pro¬ 
cesses  the  autotracker  data  contains  nu¬ 
merous  equations  which  perform  shift  and 
rotate  and  bit-wise  Boolean  operations. 
In  an  ideal  PL/M-8G  to  Ada  codo  conver¬ 
sion,  the  use  of  representation  specifica¬ 
tions  would  be  the  preferred  method  of  ob¬ 
taining  the  required  values  £»c»  Incoming 
autotracker  data.  This  would  be  the  ap¬ 
proach  most  consistent  with  sound  software 
engineering  principles.  The  Ada  compiler 
used  in  this  research  did  not  offer  the 
record  type  specif lection,  but  did  offer 
an  interface  to  ASM86  assembly  language. 
But  oven  if  the  record  type  representation 
specification  is  provided  by  on  Ada  com¬ 
piler,  thore  is  no  guarantee  that  the  ob¬ 
ject  code  generated  by  the  compiler  would 
be  efficient  enough  to  meet  performance 
requirements.  If  this  is  thu  case,  the 
software  onglneer  has  no  alternative  other 
than  an  assembly  languor  interface  in  or¬ 
der  to  satisfy  performance  requirements. 

In  the  following  section,  various  tech¬ 
niques  are  presented  which  wore  developed 
to  provide  the  functionality  of  bit  shift 
and  rotate  and  bit-wise  Boolean  operations 
required  by  the  autotracker  software.  The 
techniques  will  be  presented  in  decreasing 
order  in  terms  of  soundness  and  desirabil¬ 
ity  from  a  software  engineering  stand¬ 
point.  As  the  reader  progresses  through 
these  techniques,  several  generalities  be¬ 
come  obvious.  One  is  that  as  performance 
efficiency  improves,  there  is  a  corre¬ 
sponding  loss  in  abstraction.  As  the  ab¬ 
straction  quality  declines,  there  is  a 
corresponding  decline  in  program  under- 
standability  and  maintainability.  Gener¬ 
ally  speaking,  performance  gains  are  real¬ 
ized  by  compromising  principles  of  ‘ g/od“ 
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a&ftvarfc  tnglnearlng. 

Th#  primary  lnt*nt  for  presenting  these 
techniques  is  not  to  specifically  show  how 
to  optimise  bit  shift  and  rotate  and 
bit-wia*  logical  operations,  but  rather  to 
demonstra  the  abstraction  quality  versus 
performan««  trade-off  involved  as  progrsa- 
minc  approaches  seek  greater  and  greater 
levels  of  performance  efficiency.  Another 
prime  intent  is  to  explain  tone  mechanisms 
available  for  optimising  time  sensitive 
program  operations.  From  this  experience, 
a  sat  of  guidelines  will  be  developed  to 
aid  the  software  engineer  faced  with  chal¬ 
lenging  functional  and  performance  re¬ 
quirements  which  can  only  be  met  by  step¬ 
ping  outside  the  Ada  language.  These 
guidelines  can  serve  as  a  simple  decision 
model  when  making  decisions  concerning  the 
abstraction  quality  versus  performance 
trade-off. 


Technique  •  1  -  "Pure"  Ada. 

The  first  approach  involved  constructing 
sn  Ad*  package  which  provides  the 
equivalents  to  the  PL/H-86  functions:  SHR 
(shift  right),  SHL  (shift  left,),  SAR 
(shift  arithmetic  right),  SAL  (shift 
arithmetic  left),  ROR  (rotate  right),  and 
ROL  (rotate  left).  Bit-wise  Boolean 
operations  were  supplied  by  'within*-  a 
compiler  specific  package  called  "UN¬ 
SIGNED".  These  functions  operate  by 
analysing  on  a.  bit  by  bit  basis  each  bit 
in  an  operand  passed.  The  resulting  value 
Is  set  on  a  bit  by  bit  basis.  These  tasks 
are  performed  using  a  bit  mask  array  and 
the  bit-wise  Boolean  operations  from  the 
compiler  specific  package.  This  package 
Is  listed  in  Figure  1. 

These  functions  were  benchmark  tested 
against  their  PL/M-86  counterparts.  The 
results  showed  that  this  approach  is  hor¬ 
rendously  Inefficient.  Some  of  the  test 
results  are  included  at  the  end  of  Figuro 
1.  All  benchmark  tests  conducted  during 
this  research  were  run  on  a  Zenith  2(8 
personal  computer  running  at  8  Mhs.  The 
reasons  for  this  extreme  inefficiency  will 
become  clearer  as  subsequent  techniques 
are  analysed. 


Technique  *  2  -  “Pure"  Ada  with  constraint 
checking  deactivated. 

The  second  approach  involved  a  rewrite  of 
the  previous  algorithms  to  provide  the 
same  shift  and  rotate  functions  through 
multiplication  and  division  by  some  power 
of  two.  Again,  bit-visa  Boolean  op¬ 
erations  were  performed  by  the  compiler 
specific  package  UNSIGNED.  For  this  ap¬ 
proach  to  work,  constraint  checking  in¬ 
struction  generation  was  suppressed  at 


compile  time.  This  technique  represent# 
the  first  compromise  made  with  "good" 
software  engineering  principles.  The  com¬ 
promise  is  that  program  reliability  i*  re¬ 
duced  due  to  loss  of  constraint  violation 
detection  during  runtime.  The  program 
code  la  given  in  Figure  2. 

The  performance  of  this  set  of  algorithms 
improved  significantly  versus  the  first 
approach,  but  these  functions  were  still 
much  slower  than  their  PL/H-86  counter¬ 
parts.  Gome  of  the  test  results  are 
liated  at  the  end  of  Figure  2, 

From  these  test  results  It  can  be  seen 
that  the  speed  of  the  Ada  programs  is  * 
function  of  the  number  of  bits  shifted  or 
rotated.  Thla  la  true  because  the  proces¬ 
sor  handles  multiplication  as  repeated 
addition  and  division  as  re;  ed  subtrac¬ 
tion. 

Technique  *  3  -  Interface*  blr  lan- 
guage  routines  which  perform  t  and  ro¬ 
tate  and  bit-wise  logical  ope.  ona. 

It  became  apparent  with  the  experience  of 
the  second  approach  that  a  step  outside 
the  Ada  language  would  be  necessary  to  ap¬ 
proximate  the  performance  of  the  PL/M-86 
functions.  The  third  approach  w*s  to 
analyse  the  effect  of  using  assembly  lan¬ 
guage  routines  to  perform  the  shift  and 
rotate  functions.  The  assembly  language 
routines  built  wore  patterned  after  the 
code  seen  in  the  assembly  language  dump  of 
the  PL/M-86  benchmark  programs  using  these 
functions. 

One  of  these  assembly  language  programs  is 
shown  in  Figuro  3  -  the  SHL  function.  The 
parameters  *re  tho  bit  pattern  to  be 
shifted  and  the  number  of  bits  to  be 
shifted.  The  corresponding  Ada  program 
function  declaration  statements  which  es¬ 
tablish  the  link  to  the  assembly  language 
routine  are  also  included  at  the  end  of 
Figure  3.  Those  statements  include  the 
function  declaration,  the  pragma  INTER¬ 
FACE,  which  instructs  the  compiler  that  an 
object  module  is  to  he  supplied  for  the 
corresponding  function  name,  and  a  com¬ 
ply  spec l Me  pragma  called  pragma  INTER- 
FACE_NAME  which  completed  the  declaration. 
Note  how  the  function  parameters  must  be 
described  in  the  assembly  routine  as  some 
offset  from  an  address  contained  in  the  BP 
(base  pointer)  register. 

Benchmark  programs  were  then  written  in 
Ada  and  PL/M-86  which  contain  numerous 
equations  from  the  autotracker  software 
involving  bit  shift  and  rotate  and 
bit-wise  Boolean  operations.  The  Ada 
program's  bit-wiso  Boolean  operations  were 
performed  by  the  compiler  specific  pack¬ 
age. 
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Comparisons  of  the  complete  assembly  lan¬ 
guage  dumps  of  the  Ada  and  PL/M-86  pro¬ 
grams  provided  somo  interesting  insights 
which  would  explain  the  results  of  subse¬ 
quent  benchmark  tests. 

The  most  obvious  concern  which  arose  was 
dun  to  the  greater  number  of  instructions 
generated  in  the  Ada  program  because  of 
the  overhead  of  transferring  control  to 
and  returning  from  an  Interfaced  proce¬ 
dure.  Thin  overhead  was  Incurred  for  eaeh 
and  every  bit  shift  and  rotate  and 
bit-wise  logical  operation.  The  PL/H-86 
object  code  did  not  havo  this  overhead  - 
these  operations  were  simply  embedded  in 
the  normal  instruction  stream. 

When  further  studying  the  details  of  the 
mechanisms  involved  in  interfacing  subpro¬ 
grams,  some  inefficiencies  in  the  Ada  ob¬ 
ject  code  were  noted. 

The  user's  manual  for  the  Ada  compiler 
stated  that  all  interfaced  subprograms  are 
called  by  an  individual  FAR  call  through  a 
pointer  allocated  In  the  global,  data  area. 
The  implication  of  this  la  significant  - 
it  means  that  the  Interfaced  subprogram 
has  a  different  code  segment  value  than 
the  calling  program.  For  the  procedures 
in  the  Pli/M-86  benchmark  program,  both  the 
calling  routine  and  the  called  routine 
have  the  same  value  in  tho  code  sogment 
register. 

It  is  important  to  understand  this 
mechanism  of  subprogram  interfacing  be¬ 
cause  of  its  effect  on  execution  speed. 
In  a  call  to  and  return  from  a  procedure, 
the  control  transfer  instructions  (JHP, 
CALL,,  RET,  etc.)  break  the  current  in¬ 
struction  sequence  and  cause  program  ex¬ 
ecution  to  resume  elsewhere  in  the  program 
code.  The  assembler  uses  the  procedure 
type  label  {REAR  or  FAR)  to  determine 
whether  to  produce  an  opcode  that  changes 
only  IP  (tho  Instruction  pointer 
register),  or  an  opcode  that  changes  both 
CS  (code  segment  register)  and  IP. 

In  an  ASH86  assembly  language  program,  tho 
type  of  a  procedure  (HEAR  or  FAR)  is  indi¬ 
cated  to  the  right  of  the  keyword  PROC. 
The  type  associated  with  a  procedure  is 
used  by  the  assembler  in  determining  which 
CALL  Instruction  to  generate  for  the  pro¬ 
cedure.  If  a  FAR  is  indicated,  the  long 
form  of  the  CALL  instruction  is  used.  In 
this  case,  both  the  CS  and  IP  values  are 
changed  when  control  is  transferred,  so  a 
two-word  return  address  (CS  and  IP)  is 
pushed  on  the  stack.  For  a  NEAR 
procedure,  only  the  IP  gets  changed,  so 
the  return  address  Is  a  single  word  indi¬ 
cating  an  IP  value.  Since  there  are  two 
kinds  of  return  addresses,  there  are  two 
kinds  of  RET  instructions.  The  RET  for  a 
FAR  procedure  restores  both  CS  and  IP  us¬ 


ing  values  from  the  stack,  while  the  RET 
used  for  HEAR  procedures  reloads  only  IP 
with  tlie  word  stored  In  the  stack.  Both 
typos  of  return  instructions  are  specified 
with  t.he  mnemonic  RET  -  the  assembler  au¬ 
tomatically  decides  the  appropriate  one  to 
generate. 

The  impact  of  the  procedure  Interfacing 
overhead  on  the  benchmark  test  results  was 
substantial  -  the  Ada  program  was  45X 
slower  than  Its  PL/M-86  counterpart. 
While  the  performance  difference  has  sub¬ 
stantially  narrowed  when  compared  to  the 
aocond  approach,  this  difference  was  still 
not  narrow  enough  for  the  Ada  version  to 
satisfy  performance  requirements. 


Technique  9  4  -  Narrowing  the  performance 
gap  by  minimixing  the  number  of  assembly 
language  program  interfaces. 

Since  the  subprogram  interfacing  overhead 
is  a  constraint  which  could  not  be  re¬ 
moved,  the  only  option  available  for  fur¬ 
ther  performance  improvement  was  to  reduce 
the  amount  or  frequency  of  calls  to  the 
interfaced  assembly  routines.  Closer 
analysis  of  the  autotracker  aoftware 
showed  that  most  of  the  equations  using 
logical  and  shift  and  rotate  operators 
were  concentrated  in  two  areas  of  the  pro¬ 
gram. 

The  fourth  approach  involved  moving  those 
parts  of  the  equations  which  performed 
those  operations  to  two  interfaced  assem¬ 
bly  language  routines  -  each  routine  cor¬ 
responding  to  one  of  the  program  sections 
where  these  operations  ware  clustered. 

Minimizing  the  amount  of  the  interfaced 
procedure  call  and  return  overhead  did 
successfully  narrow  the  performance  gap. 
The  Ada  benchmark  program  was  now  only  15X 
slower  than  the  PL/M-86  version.  All  in¬ 
volved  Ada  program  variables  were  passed 
to  the  assembly  language  programs,  along 
with  the  addresses  of  each  of  the 
variables.  It  was  necessary  to  pass  the 
addresses  of  these  variables  in  order  for 
the  assembly  language  program  to  store 
calculation  results  in* the  appropriate  Ada 
variable  memory  location. 

This  approach  represents  a  severe  and  un¬ 
desirable  compromise  with  effective  soft¬ 
ware  design  principles.  In  effect,  the 
abstraction  of  the  problem  solution  virtu¬ 
ally  disappears  from  the  Ada  program.  It 
is  shifted  to  the  assembly  language  pro¬ 
gram,  where  the  problem  solution  is  at  a 
greatly  reduced  level  of  abstraction.  The 
assembly  language  code  is  naturally  far 
more  difficult  to  understand  and  maintain. 
The  interface  to  the  assembly  language 
routine  is  very  messy  -  each  affected 
variable  and  its  address  (obtained  via  the 
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ADDRESS  attribute)  must  bo  passed. 

This  interface  is  all  the  programmer  sees 
when  viewing  the  Ada  code  -  thore  is  not 
the  slightest  hint  of  what  the  program  is 
dealing  with  or  attempting  to  solve.  The 
program  can  now  be  maintained  with  the  aid 
of  extremely  lucid  and  verbose  documenta¬ 
tion,  and  an  expert  assembly  language  pro¬ 
grammer.  This  approach  obviously  has  un¬ 
desirable  ramifications  from  the  program 
manager's  standpoint. 

With  the  performance  differential  narrowed 
to  1SX,  this  is  the  first  technique  which 
becomes  feasible  given  the  imposed  hard¬ 
ware  and  software  constraints.  However, 
the  program  management  was  interested  in 
seeing  if  the  performance  gap  could  be 
narrowed  even  further. 


Technique  IS-  Reducing  the  siae  of  the 
parameter  list. 

Analysis  of  the  object  code  resulting  from 
the  previous  technique  showed  a  tremendous 
amount  of  overhead  involved  in  the  call  to 
and  return  from  the  two  Interfaced  assem¬ 
bly  routines.  Every  parameter  passed  in 
the  function  call  had  to  be  "pushed”  on 
the  parameter  stack.  Likewise,  every  pa¬ 
rameter  had  to  be  "popped*  from  the  param¬ 
eter  stack  on  return  from  the  interfaced 
routine.  The  parameter  list  was  sizeable 
for  each  routine  -  each  affected  variable 
and  its  address  were  leaded  on  and  removed 
from  the  parameter  stack. 

The  final  technique  sought  to  reduce  this 
overhead  by  reducing  the  size  of  the  pa¬ 
rameter  list  itself.  This  was  accom¬ 
plished  by  placing  all  of  the  variables  to 
be  passed  to  the  assembly  language  routine 
in  a  single  record  type  object  in  the  Ada 
program,  and  then  passing  only  the  start¬ 
ing  address  of  this  record  to  the  inter¬ 
faced  routine.  Thin  eliminated  all  of  the 
parameter  “push”  and  "pop"  activity  asso¬ 
ciated  with  the  procedure  call  and  return, 
except  for  the  starting  address  of  the  Ada 
record  which  in  effect  contained  the  pa¬ 
rameter  list. 

Naturally,  the  assembly  language  routine 
had  to  be  built  with  the  knowledge  of  the 
exact  structure  of  the  Ada  record  contain¬ 
ing  the  parameter  list.  First,  the  exact 
physical  layout  of  the  components  within 
the  record  had  to  be  determined.  A  spe¬ 
cial  program  was  written  which  used  the 
POSITION  attribute  to  dissect  and  deter¬ 
mine  the  exact  physical  layout  of  the 
record  components.  The  POSITION  attribute 
provides  the  offset  of  a  particular  record 
component  with  respect  to  the  first  of  the 
storage  units  within  the  record.  With 
this  structural  information  known,  the  as¬ 
sembly  language  routine  could  be  written 


to  address  the  locations  of  the  Ada  record 
components,  given  the  starting  address  of 
the  record  as  input. 

Benchmark  testa  showed  that  the  Ada  vs. 
PL/M-8B  performance  gap  kail  narrowed  to 
less  than  6*.  This  was  deemed  an  accept¬ 
able  performance  level. 

This  technique  probably  represents  the 
most  powerful  way  to  overcome  performance 
bottlenecks  shout  of  rewriting  the  com¬ 
piler  itself.  Unfortunately,  a  reasonable 
level  of  program  understandability  and 
maintainability  has  completely  vanished 
here.  Thi3  technique  adds  a  new  level  of 
complexity  over  the  fourth  technique.  It 
is  also  less  maintainable.  If  any  vari¬ 
able  or  equation  at  the  source  level 
changes,  the  assembly  routine  must  be  re¬ 
written.  Any  change  to  a  record  compo¬ 
nent^)  within  the  parameter  list  embedded 
in  the  Ada  record  type  object  would  upset 
the  "hard-coded"  knowledge  of  the  physical 
arrangement  of  Ada  components  within  the 
record.  If  an  Ada  application  had  many 
such  performance  bottlenecks  which  could 
only  be  solved  using  this  kind  of  ap¬ 
proach,  one  might  legitimately  question 
the  merits  of  moving  to  a  radically  dif¬ 
ferent  solution  such  as  a  new  compiler 
and/or  hardware  architecture.  This  can 
sometimes  be  considered  a  radical  solution 
for  a  complex,  embedded  military  applica¬ 
tion  nearing  maturity. 


Lessons  learned. 

The  order  in  which  the  tuchniques  were 
presented  progressed  from  higher  to  lower 
(or  nonexistent)  levels  of  abstraction, 
from  lesser  to  greater  compromises  with 
sound  software  engineering  principles,  and 
from  higher  to  lower  levels  of  maintain¬ 
ability  and  understandability,  and  con¬ 
versely,  from  lower  to  higher  levels  of 
performance  efficiency. 

There  are  specific  lessons  In  this  paper 
for  the  software  engineer  trying  to  over¬ 
come  functional  or  performance  bottlenecks 
encountered  at  the  "pure"  Ada  language 
level,  and  lessons  of  a  general  nature  for 
engineering  management  responsible  for 
providing  direction  on  how  such  technical 
problems  are  to  be  managed. 

In  solving  a  performance  or  functional 
bottleneck  by  resorting  to  a  step  outside 
the  Ada  language,  a  list  of  possible  ap¬ 
proaches  should  be  generated.  This  list 
should  be  ordered  In  terms  of  desirability 
from  a  soundness  of  design,  reliability, 
and  maintainability  standpoint.  Benchmark 
programs  should  be  developed  and  analyzed 
in  terms  of  ability  to  meet  performance 
requirements.  The  approach  selected  to 
solve  the  bottleneck  should  not  necessar- 
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ily  '•>*  the  most  performance  efficient. 
Generally,  the  approach  selected  should  be 
the  one  Involving  the  highest  level  of  ab¬ 
straction  quality,  understandabillty,  and 
maintainability,  while  still  meeting  per¬ 
formance  requirements.  Using  this  guide¬ 
line  as  a  decision  model  should  help  to 
Minimise  total  system  life  cycle  costs. 

On  any  sisable  embedded  systems  develop¬ 
ment  program,  it  is  Important  for  systems 
engineering  management  to  retain  a  library 
of  techniques  available  to  overcome  per¬ 
formance  and  functional  bottlenecks.  Sys¬ 
tems  engineering  should  also  provide  di¬ 
rection  on  how  to  select  and  manage  the 
implementation  of  those  techniques. 
Documentation  standards  should  become  more 
rigid  and  require  more  time  and  effort  for 
the  lowest  level  approaches.  Without  such 
standards,  the  performance  bottleneck 
solvod  today  could  become  tomorrow's  main¬ 
tenance  nightmaro. 
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Shift  and  Rotate  Function  Test  -  300,000  Iterations 
(PL/M  vs.  Ada  Using  Bit  Masking  Algorithms) 

Operation  Pattern (operand)  Count(«  bits  moved)  Ada(seconds)  PL/M(seconds) 


SHL  65,535  8  123  6 

ROR  255  8  214  6 


Figure  1.  Program  code  for  technique  #  1 
and  benchmark  test  results 
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Shift  and  Rotate  Function  Test  -  300,000  Iterations 
(PL/M  vs.  Ada  Using  Muitiplication/Division  Algorithms)* 

Operation  Pattern(operand)  Count(#  bits  moved)  Ada(seconds)  PL/M(seconds) 


SHR 

65,535 

8 

34 

6 

SHL 

255 

1 

14 

6 

SHL 

1 

15 

52 

6 

SHL 

1 

8 

34 

6 

SAL 

255 

1 

14 

6 

SAR 

65,535 

8 

41 

6 

ROL 

255 

8 

65 

6 

R0R 

255 

8 

65 

6 

Figure  2.  Program  code  for  technique  #  2 
and  benchmark  test  results. 
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NAME  SHL..PKG 
SHl.CODE  SEGMENT  BYTE  PUBl.IC 
ASSUME  CS:SHL_CODE 

;  The  following  defines  how  arguments  will  be  ecceaaed. 

;  (Conpare  with  the  Ada  DETAIL  messages  in  the  compiler  Hating- ) 


PAT 

EQU 

(BP+6) 

CNT 

ECU 

(BP»8) 

PUBLIC 

LEFTSH 

LEFTSH 

PROC 

FAR 

PUSH 

BP 

! 

Establish  frame  for  addressability  to 

MOV 

BP.SP 

• 

parameters  from  interfaced  subprogram 

MOV 

AX, PAT 

• 

Move  value  to  be  shifted  into  word  register  AX 

MOV 

CL, CNT 

; 

Move  number  of  bits  for  value  to  be  shifted 

• 

into  byte  register  CL 

SHL 

AX.  CL 

i 

Perform  shift 

1 

MOV 

SP.BP 

i 

Destroy  the  frame 

POP 

BP 

RET 

4 

! 

Return  to  Ada  caller,  popping  IN  parameters 

LEFTSH 

ENDP 

SHL_COD£  ENDS 
END 


function  SHL(PAT  :  WORD  ;  CNT  :  BYTE)  return  WORD: 
pragma  I NTERFACE ( ASSEMBLER , SHL ) ; 
pragma  INTERFACE_NAHE('5KL, "LEFTSH" ) j 


Figure  3.  A  sample  assembly  language  program  interfaced 
to  an  Ada  benchmark  program  to  provide  the 
shift  left  function,  and  the  associated  Ada 
program  function  declaration  statements. 
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ABSTRACT 

Ada  can  serve  as  a  highly  graphic, 
interactive  and  expressive  languago  for 
the  project  manager.  When  equipped  with  a 
graphics  package  and  maximum  use  of 
separate  compilation  units,  Ada  can  be 
used  to  simulate  future  systems  in  order 
to  provide  necessary  feedback  to  modify 
the  statement  of  work  early  in  the  design 
phase  to  help  ensure  first  pass  success  of 
delivered  hardware.  The  simulated  system 
can  lead  to  the  exploitation  of  common 
hardware  platforms  through  system  recon¬ 
figuration  under  software  control. 


INTRODUCTION 

Risk,  budget  and  time  are  critical 
elements  in  project  management.  This  is 
particularly  truo  for  future  military 
systems.  Military  projects  begin  with  a 
Required  Operational  Capability  (ROC) . 
The  ROC  is  developed  through  an  evaluation 
of  the  battlefield  commander's  needs  and 
the  threat  analysis.  A  project  manager 
(PM)  is  then  selected  to  transform  the  ROC 
into  a  statement  of  work  (SOW) . 

Usually  the  first  tangible  feedback 
from  the  SOW  is  a  hardware  prototype  of 
the  system  developed  under  contract.  The 
SOW  must  be  precise,  lest  the  prototype 
will  not  conform  to  the  ROC.  The  cost  due 
to  changes  in  the  SOW  are  directly 
proportional  to  the  elapsed  tine  in  the 
project  cycle.  Consequently,  changes 
early  in  the  design  phase  are  less  costly 
than  at  the  time  of  delivery  of  a  working 
prototype.  Costs  due  to  changes  in  the 
SOW  beyond  this  phase  typically  rise 
exponentially.  Design  and  procedural 
anomalies  revealed  in  operational  tests 
may  indicate  preferred  changes  to  the  SOW, 
but  the  impact  on  budget  and  time  often 
prohibits  this  course  of  action. 

This  paper  will  examine  the  use  of  a 
"software  mockup"  for  a  candidate  system 
under  development.  A  software  mockup  is 
defined  as  an  interactive  and  graphic 
computer  simulation  derived  from  the 


statement  of  work.  It  functions  at  a  high- 
level  of  abstraction  which  can  be  used  by 
the  PM  as  well  as  by  soldiers  who  will 
utilize  the  equipment.  It  is  postulated 
that  a  system  simulation  in  Ada  provides  a 
cheaper  and  faster  design  assessment  for 
use  by  the  project  manager  than  obtainable 
from  a  hardware  prototype. 


Ada  vs.  VHDL 

Hardware  description  languages  (KDLs) 
have  been  available  for  many  years  but 
there  has  been  no  clear  standard  until  the 
DoD  Very  High  Speed  Integrated  Circuit 
(VHSIC)  program  spawned  the  development  of 
the  VHSIC  HDL  (VHDL),  now  IEEE  Standard 
1076.  VHDL  provides  the  capability  for 
describing  the  behavior,  data  flow,  and 
structural  models  of  digital  circuits,  but 
it  is  neither  interactive  nor  graphic  at 
the  system  level. 

Despite  the  tremendous  impact  that 
VHDL  is  having  on  the  electronics 
industry,  VHDL  in  its  present  form  does 
not  provide  ar.  interactive  simulation 
interface  for  user  testing  and  executive 
decision  making.  In  contrast,  and  with  an 
appropriate  graphics  package,  Ada  can 
simulate  the  behavior  of  a  system  in  a 
user-friendly  and  interactive  environment 
providing  useful  feedback  to  the  PM.  The 
suitability  of  using  Ada  for  lowor  level 
simulation  of  digital  signal  processing 
systems  is  presented  by  [Happel  and 
Pctrasko] . 


THE  METHODOLOGICAL  MODEL 

Creating  the  software  mockup  begins 
at  a  high  level  of  abstraction.  The  man- 
machine  interface  is  decomposed  into  two 
separate  units  -  the  man  and  the  machine. 
In  the  Ada  paradigm,  both  can  be  viewed  as 
tasks.  The  man  is  an  active  or  pure  user 
task  which  from  time  to  time  makes  use 
(calls  an  entry)  of  the  machine  which,  in 
the  simplest  case,  is  a  passive  or  pure 
server  task.  The  machine  will  accept 
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valid  entry  calls.  When  modeled  correctly 
the  Machine  task  will  react  to  human  input 
according  to  its  functional  specification 
as  given  in  the  SOW,  The  synchronization 
of  the  Man  with  the  machine  is  modeled  as 
a  rendezvous  between  the  calling  and 
called  tasks  in  Ada.  Usually  a  change  in 
the  machine's  state  will  occur  as  a  result 
of  the  rendezvous  which  can  be  represented 
graphically  on  a  CRT. 

A  graphic  nockup  driven  by  Ada 
software  can  be  used  as  a  valuable  tool  to 
assess  response  timo,  training  require¬ 
ments,  incorrect  steps  in  procedure,  and 
alterations  to  the  operator's  manual.  The 
feedback  to  tho  PM,  through  visual  and 
hands-on  interaction  with  or  without 
soldier  testing,  holps  to  gather  valuable 
Insight  into  how  well  the  SOW  was 
interpreted.  Although  the  need  for 
preciseness  in  tho  SOW  is  not  diminished 
by  this  method,  changes  to  the  software  at 
this  stage  in  tho  system  development  are 
far  less  costly  and  faster  than  if  changes 
would  have  to  be  made  after  delivery  of 
hardware.  In  tho  final  analysis,  recompi¬ 
lation  of  software  is  more  acceptable  than 
reconfiguration  of  hardware.  Maximum  use 
of  soparate  compilation  in  Ada  adds 
greater  efficiency  to  the  recompilation 
process. 


VALIDATING  THE  METHODOLOGICAL  MODEL 

A  system  in  the  test  phase  of 
development  was  chosen  to  validate  the 
methodological  model.  Known  as  the  Water 
Quality  Analysis  Unit  (WQAU) ,  its  purpose 
was  to  sample  the  purity  of  tactical  water 
supplies  produced  by  the  currently  fielded 
Reverse  Osmosis  Processing  Unit.  Present¬ 
ly,  such  testing  is  performed  using  vet 
chemistry  kits  which  would  be  replaced  by 
the  electronic  WQAU.  An  appropriate  SOW 
was  generated  by  a  PM  for  the  proponent 
Army  command v 


A  prototype  was  designed  and  built 
under  contract  as  shown  in  Figure  1. 


Figure  1.  The  delivered  WQAU  prototype. 


The  unit  did  not  pass  its  operational 
field  test.  It  failed  the  drop  test,  was 
12  pounds  overweight,  and  did  not  give 
consistent  readings.  Soldier  interface 
difficulties  were  also  revealed  during  the 
test.  For  example,  the  user  manual 
expressly  states  that  the  WQAU  must  be 
placed  in  the  CALIBRATE  mode  when  initial¬ 
ly  turning  on  the  power.  This  was  easily 
defeated  or  Ignored  by  leaving  the 
mechanical  toggle  switch  in  the  MEASURE 
mode. 

Five  attributes  of  water  had  to  be 
measured  -  pH,  total  dissolved  solids, 
temperature,  turbidity,  and  percent 
chlorine.  Each  attribute  function  was 
selected  by  a  five  position  switch.  An 
analog  probo  provided  current  and  voltage 
levels  to  the  WQAU  which  was  then 
processed  and  displayed  digitally.  To 
consorvo  battery  power,  a  five  digit  read¬ 
out  was  required  to  display  for  is  seconds 
and  then  go  off.  This  requirement, 
although  correctly  engineered,  did  not 
take  human  factors  into  account.  As  would 
later  be  demonstrated,  a  software 
simulation  would  have  flagged  the  latter 
two  faults  before  developing  hardware  as 
well  as  given  insight  to  an  alternative 
hardwaro  platform  leading  to  a  lighter 
weight  package. 


SIMULATOR  DEVELOPMENT 
The  Machine  as  a  Task 

As  stated  earlier,  the  man  and  machine 
can  be  modeled  as  tasks  to  request  and 
accept  services.  The  calling  task  is  man; 
the  called  task  is  the  wqau.  Thus,  any 
switch  position  that  can  be  set  by  the 
human  task  is  modeled  as  an  entry  into  the 
WQAU.  Changing  the  switch  position 
effects  the  machine  depending  on  the 
condition  of  its  present  state.  Example: 
an  entry  to  READ  the  pH  of  water  would  be 
accepted  but  have  no  effect  if  the  power 
switch  is  OFF.  Changes  in  state  are 
initiated  from  a  keyboard  and  a  graphic 
response  is  produced  on  a  CRT  (Figure  2.) 
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Ta sk  MACHINE  is  represented  as  follows: 

taih  MACHINE  is 

•ntry  mad; 

•ntry  OH; 

•ntry  OFF; 

•ntry  MEASURE; 

•ntry  CALXSXATE; 

•ntry  pK; 

•ntry  turbidity; 

•ntry  CMLORXNE; 

•ntry  ton; 

•ntry  TEMPERATURE; 

•nd  MACMXNE; 

Further  discussion  on  the 
appropriateness  of  the  task  modal  will  not 
continue  here  except  to  say  that  entries 
without  parameters  correctly  convey  the 
physical  Kenning  of  a  switch  -  a 
rendesvous  cakes  place,  hut  nothing 
physically  passes  from  huaan  to  aachino. 
The  machine  noroly  resets  to  the  stinulus 
that  a  specific  contact  has  boon  cade. 


procedure  SET  VXDTM  so; 
procedure  set“mxotnjU2  ; 
procedure  invisible” 
procedure  black_f; 
procedure  red^fT 
procedure  green_f; 
procedure  yellow_f; 
procedure  blue_f7 
procedure  *agenta— f; 
procedure  cya n_f;“ 
procedure  whitest; 
procedure  black”b; 
procedure  red_b7 
procedure  green_b; 
procedure  yellow_b; 
procedure  blue_b7 
procedure  magenta^b; 
procedure  cyan_b;~ 
procedure  white  b; 

•nd  SET  LOCATION;” 


Figure  3.  Package  8et_Location 


An  Ada  Craphlcs  Package 

In  order  to  provide  a  friendly 
interactive  graphics  environnont  tc 
portray  the  WQAU  in  software,  it  was 
necessary  to  build  a  graphics  package.  As 
widely  known,  the  Ada  package  STANDARO  is 
rudimentary,  and  provides  only  primitive 
types  and  operations.  Graphics  is  not 
part  of  tho  language,  but  Ada  language 
designors  expected  that  packages  would  be 
written  by  software  developers  as  required 
and  made  available  for  later  reuse.  For 
this  project,  a  package  SET.LOCATION  was 
initially  developed  in  monochrome  on  a 
superminicomputer  and  later  extended  to 
incorporate  color  for  a  PC  host.  This 
package  provided  a  tool  to  develop  a 
likeness  of  the  WQAU  on  a  CRT  by  multiple 
selection  of  a  row/column  and  a  color  from 
procedures  in  the  graphics  package  when 
called  with  a  specified  character  from 
procedure  PRINT_SCREEH.  The  package 
specification  for  SET_LOCATION  is  shown  In 
Figure  3 . 


package  8ET_LOCATION  is 
USE  A8CXX; 

X,  Y  :  INTEGER; 

TEXT  :  STRING (1.. 80 ) ; 

CLR  :  constant  STRING:= 

ESC  i  8  E8C  i  «[1;1H»; 

procedure  MOVE  (X,Y  :  INTEGER); 
procedure  set_normal; 
procedure  REV; 
procedure  BOLD; 
procedure  UNDERLINE; 
procedure  BLINK; 
procedure  NO_REV; 
procedure  NO~BOLD; 
procedure  NO~UNDERLIHE; 
procedure  N0~BLXNK; 


Tho  execution  of  each  procedure  in 
SET.LOCATION  outputs  an  appropriate  escape 
sequence  derived  from  the  terminal 
technical  manual.  For  example,  to  take 
advantage  of  a  132  column  terminal  width, 
"procedure  SET_WIDTH_132"  is  selected. 
The  procedure  body  is  hidden  in  package 
body  SET_LOC,\TION  as 


procedure  flETJIIDTH_132  is 
begin  "" 

put (ESC  i  »[?3h«); 

•nd; 


With  a  sufficient  graphics  capability 
now  in  place,  a  bit  of  artistry  was 
applied  to  adequately  represent  the  WQAU 
on  the  CRT  (Figure  2)  through  the 
execution  of  procedure  PRINT_SCREEN 
declared  in  package  WQAU.  A  help  "command 
was  implemented  to  assist  the  user  with 
allowable  interactive  entry  calls  to  task 
MACHINE.  Thus  through  the  graphics 
interface,  any  user  operation  that  could 
be  performed  on  the  hardware  prototype 
could  be  commanded  from  the  keyboard  and 
the  simulated  result  would  be  displayed. 
Naturally,  only  allowable  commands  had  any 
effect.  Any  illegal  commands  or  input 
errors  had  a  null  effect  through  judicious 
use  of  exception  handling.  Software 
development  was  accelerated  by  using 
separately  compiled  modules  developed  in 
the  top-down  design.  A  partial  outline  of 
the  WQAU  simulator  in  Ada  is  shown  in 
Figure  4. 
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with  SETJLOC,TEXT  XO;  ua*  SET  LOC,TEXT  10; 
packaga  »QAU  is  ~ 

typa  U*er_/,ctiox  is  (TARE  OUT, sot  x, 
SOL_l ,  SOL_ 3  ,  READ,” 

OW ,  OFT,  PIC ,  TURBIDITY  , 
CRLORXNE,TOS,TENR, 
MEASURE, CALX IRATE, RELY) ; 

aubtypa  K„OR_C  is  USER  ACTXOR  rang. 

MEASURE. .CALIBRATE; 

typa  STATUS  is  —  machina  initial  stats 
—  proba  not  in  watar 

record 

T  XI>  E_0»_x  E  AS  U  RE 

J^STRXMOd.  .10)  is«YN  «• 

POWER  :  SOOLEAM  s=  FALSE; 

MEAS  OR  CALXS 

:  M_OR_C_TYPE  SSCALXBRATE; 
SOLUTXOM  :  STRXMC(1. .*) ja”AIR. DAT*' ; 
and  xaoord; 

CURREKT_STATUS  :  STATUS; 

COMO  “  ;  USER  ACTXOK ; 

READY  :  »OOLEAMx*FALSE; 

—  I/O  packaga  instantiation 
procadura  frint  screen; 
procadura  DISPLAY; 

procadura  KELP;  --  paraissabla  actions 
procadura  PLACE  PROSE;  —  in  watar 
procadura  OPERATION; 
and  NQAUJP; 

packaga  body  NQAU  P  is 

procadura  print“screen  is  saparata; 
procadura  DISPLAY  is  saparata; 
procadura  KELP  is  saparata; 
procadura  PLAce_electrode  is  saparata; 
procadura  OPERATION  is  saparata; 
and  NQAUJP; 

saparata (WQAU  P) 
procadura  OPERATION  is 
task  MACHINE  is 

—  as  shown  aurliar 
and  MACHINE; 

task  body  MACHINE  is  saparata; 
bagin  —  aachina  op. ration 
null; 

and  OPERATION; 

Pigur*  4.  WQAU  packaga  (partial) 


Software  Development 

The  software  effort  began  as  a  student 
project  in  an  undergraduate  Ada  course. 
The  student  was  provided  with  a  SOW  and  a 
photograph  of  the  WQAU  prototype. 
Development  proceeded  on  a  VAX  8800. 
Approximately  1200  linen  of  code  were 
written  to  produce  a  working  system  level 
simulator.  Through  a  summer  student 
intern  program,  the  software  was  rehosted 
on  a  government  owned  VAX-11/780  and  then 


to  a  PC/AT  compatible  machine  using 
validated  Ada  compilers,  only  one  line  of 
code  was  changed  when  moving  to  the  PC  duo 
to  a  package  scope  anomaly.  Once  this 
transportability  issue  was  resolved,  the 
graphics  package  was  modified  to 
facilitate  the  use  of  color.  The  total 
software  development  effort  required  one 
(undergraduate)  man-month. 


EVALUATING  THE  SIMULATOR 

The  PC  provided  a  mobile  platform  for 
demonstration  and  testing  of  the 
simulator-  Except  for  the  real  analog 
probes  (portrayed  on  the  CRT),  the 
graphics  responded  identically  to  the 
prototype  hardware.  The  15  second  display 
of  the  five  digit  read-out,  as  specified 
in  the  hardware  requirement,  was 
consistently  is  seconds  in  the  software 
simulation.  This  was  accomplished  through 
use  of  the  Ada  daisy  statement.  Actual 
field  tests  of  the  hardware  prototype 
revealed  that  soldiers  were  not  happy  with 
the  duration  of  tho  delay.  They  were  able 
to  view  and  record  a  measurement  in 
approximately  7  seconds  and  were  ready  to 
proceed  to  tho  next  reading.  The  cost  and 
development  time  to  implement  a  hardware 
change  would  havo  to  be  weighed  against  a 
less  than  optimally  human  engineered  unit. 

In  contrast,  a  change  to  the  delay 
statement  in  tho  Ada  simulator  could  be 
implemented  on  the  spot  by  editing  and 
separately  compiling  task  body  MACHINE. 
Changes  at  virtually  no  cost  and  in  near 
real-time  could  be  tested  again  for  the 
human  response  to  the  reengineered 
condition.  It  is  conjectured  here  that 
project  managers  would  be  prone  to  make 
SOW  adjustments  to  improve  system 
performance  when  changes  early  in  the 
design  phase  would  havo  little  impact  on 
budget  and  schedule. 


Observations  from  the  WQAU  simulator 
in  the  laboratory  have  had  a  more  profound 
effect  than  just  the  delay  modification 
above.  Software  could  guide  the 
operator's  stops  to  ensure  that  the 
CALIBRATE  function  was  performed  before 
MEASURE  as  stated  in  the  operator's 
manual.  This  was  not  possible  in  hardware 
using  a  two  position  toggle  switch.  Thus 
a  round  of  "what  ifs"  began  to  emerge  as 
interaction  with  tho  simulator  continued. 


•  what  if  a  touch  panel  display  replaced 

all  mechanical  switches? 

•  what  if  the  software  driving  the 
display  prohibited  illegal  courses  of 
action? 
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•  what  if  the  simulator  was  downloaded  to 
a  PC  laptop? 

•  what  if  an  A/0  converter  Interfaced  the 
analog  probe  with  the  PC  laptop? 

•  what  if  an  off-the-shelf  PC  laptop 
costing  S1000  and  weighing  12  pounds 
replaced  a  custom  engineered  unit 
costing  $5000  and  weighing  45  pounds? 


Figure  5.  The  WQAU  Ada  simulator 
hosted  on  a  PC  laptop. 


Tho  last  hypothesis  is  shown  in 
Figure  5.  It  does  not  take  into  account 
tho  A/O  convertor  and  weight  of  the  probe, 
but  estimates  are  good  that  this  is  a  cost 
effective  solution  to  the  original  SOW. 
Tho  project  manager  might  be  expected  to 
conduct  a  feasibility  study  for  this 
course  of  action.  In  this  project,  tho 
Ada  PC/AT  executable  code  for  the 
simulator  was  downloaded  without 
modification  to  a  PC  laptop  computer  (on 
which  this  paper  was  written)  and  used  for 
inter-office  demonstrations. 


NEXT  GENERATION  SYSTEMS  DEVELOPMENT 


A  reconfigurable  set  of  common 
platforms  is  the  cornorstone  of  che  Army's 
future  Armored  Family  of  Vehicles  and  the 
heart  of  the  OoD  non-dovalopsental  item 
philosophy.  Electronic  sys'.ems  are  even 
more  adaptable  than  mecha..ical  systems  to 
a  •’software  prototyping  before  metal 
bending"  methodology.  With  software 
reconfiguration  and  control,  the  simulator 
itself,  carefully  adjusted  early  in  the 
design  phase,  has  the  potential  to  become 
the  platform  for  the  developed  system. 

Currently,  computer-aided  tools  are 
being  developed  which  will  svnthesize 
software  descriptions  to  silicon  compilers 
for  the  automated  generation  of 
application  specific  integrated  circuits 
(ASICs) .  With  those  tools,  software 
simulation  may  become  a  computer-aided 
project  management  gateway  to  a  totally 
integrated  design  and  fabrication  process. 


CONCLUSION 

Ada  provides  a  rich  set  of  abstract 
data  types  which  allows  for  high  level 
modeling  and  simulation  of  future 
electronic  systems.'  Because  of  the 
ability  to  write  an  intoractivo  graphics 
package  in  Ada,  functional  behavior  of 
systems  can  be  represented  in  a  visual 
display  suitable  for  tasting  and  analysis 
before  the  system  hardware  is  built. 
System  testing  under  software  control 
provides  a  rapid  prototyping  feedback 
mechanism  for  the  project  manager  to 
modify  the  statement  of  work  early  in  the 
design  phase  before  lengthy  and  costly 
developmental  hardware  prototypes  are 
built.  Such  simulators  can  give  insight 
to  common  hardware  platforms  which  can  be 
reconfigured  under  software  control. 
Those  common  platforms  become  system 
specific  when  adapted  to  unique  front  end 
sonsorc.  The  Ada  programming  language 
facilitates  modeling,  portability  and 
reconfiguration  when  cquippad  with  a 
graphics  capability  and  when  separate 
compilation  is  exploited. 


It  is  envisioned  that  future  systems 
development  will  come  to  depend  on 
software  prototyping  before  committing 
scarce  resources  to  build  hardware 
prototypes.  This  is  particularly  true 
when  there  is  a  low  probability  of  first 
pass  success  as  system  complexity  and 
interoperability  uncertainties  increase. 
Further,  families  of  common  processor  and 
display  hardware  nay  be  developed  which 
are  reconfigurable.  Systems  will  be 
characterized  by  coupling  unique  front 
ends  to  a  mix  of  standard  platforms  under 
software  control.  Electronic  warfare 
systems  are  likely  initial  candidates 
(Poza) . 
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THE  ADA  SOFTWARE  DEVELOPMENT  METHODOLOGY  EVALUATION 
AND  SELECTION  PROCESS t  FACT  OR  MYTH? 


by 

Sterling  J.  McCullough 


Computer  Technology  Group,  Ltd. 
Washington,  DC 


ABSIBAEI 

One  of  the  most  Important  activities 
that  is  performed  during  the 
development  of  a  software  application 
is  the  selaction  of  a  software 
development  method  for  use  on  the 
project.  The  choice  of  a  method  has  a 
major  impact  on  the  quality  of  the 
resulting  design,  implementation,  and 
documentation  and  on  the  productivity 
of  the  project  personnel. 

During  a  recently  completed  study,  the 
author  found  that  a  number  of  the  Ao‘a 
developers  that  were  Interviewed  had 
only  a  minimal  understanding  of  the 
approach  to  be  used  in  selecting  a 
method  for  use  on  an  Ada  project.  The 
purpose  of  this  paper  is  to  present  a 
proposed  approach  for  evaluating  and 
selecting  a  software  development 
method  for  use  on  an  Ada  project. 


I.  BACKGROUND 

From  November  1987  to  May  1988, 
Computer  Technology  Group  (CTG) 
provided  support  to  Sonicraft,  Inc.  in 
performing  a  methods  study  for  the 
Center  For  Software  Engineering,  U.S. 
Army  Comunications  and  Electronics 
Command  (CECOM) .  The  study  was 
entitled  “Methodology  Study  For  Real- 
Time  Ada  Problems”  [Soni88].  The 
purpose  of  this  study  was  to  perform  a 
theoretical  analysis  of  the  impact  of 
a  method  on  a  set  of  generic  Ada 
problems  that  had  been  identified  by 
Sonicraft  in  a  previous  study  for  U.S. 
Army  CECOM  (Soni87).  The  theoretical 
results  were  then  compared  to  actual 
results  obtained  from  interviews  with 
Ada  developers  that  had  current  or 
recent  experience  in  the  development 
of  real-time  embedded  Ada 
applications. 

The  study  results  which  formed  the 
basis  for  this  paper  were: 


1)  The  method(s)  selected  for 
use  on  the  projects  had  an 
impacted  on  a  large  number  of 
the  generic  Ada  problems, 
particularly  in  the  area  of 
project  management. 

2)  Many  of  the  interviewees  had 
a  minimal  understanding  of 
the  approach  to  be  used  in 
selecting  a  method  to  be  used 
on  an  Ada  project. 

3)  Most  of  the  interviewees  had 
selected  methods  for  use  on 
their  Ada  projects  based 
primarily  on  subjective 
factors  such  as  familiarity 
with  the  method,  word  of 
mouth,  or  recommendations 
from  vendors. 


2.  STATEMENT  OF  PROBLEM 

After  analyzing  the  study  results,  CTG 
felt  that  the  results  pointed  out  a 
potentially  widespread  need  for 
education  and  training  in  the 
evaluation  and  selection  of  methods 
for  use  on  Ada  projects. 


3.  QBJSgUVES 

To  address  the  problems  stated  in 
Section  2,  the  author  then  performed 
his  own  study  titled  “Evaluation  And 
Selection  Of  Methods  For  Use  On  Ada 
Projects"  [CTG88] .  The  purpose  of 
this  study  was  to  develop  a  proposed 
approach  for  evaluating  the 
suitability  of  a  method  for  use  on  an 
Ada  project. 

The  objectives  of  the  Ada  Methods 
Evaluation  and  Selection  Study  were 
to: 
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1)  Develop  a  sat  of  project 

characteristics  to  be  used  in 
categorizing  the  type  of 
application  to  be  developed 
and  establishing  the  relative 
importance  of  the  method 
features  for  the  evaluation. 

2)  Develop  criteria  to  be  used 

in  evaluating  the  suitability 
of  a  method  for  use  on  an  Ada 
project,  based  on  a  set  of 
method  features. 

3)  Develop  an  approach  for  using 

the  method  features  and 
project  characteristics  to 
evaluate  the  suitablity  of  a 
method  for  use  on  a 
particular  Ada  project. 

4)  Provide  a  quantitative  means 

to  determine  the  suitability 
of  a  method  for  use  on  a 
particular  Ada  project.  This 
information  can  be  used  to 
support  or  establish  the 
validity  of  a  method 
selection  that  was  made  based 
primarily  on  qualitative 
(subjective)  data. 


4.  OVERALL  APPROACH 

The  task  of  determining  the 
suitability  of  a  method  for  use  on  an 
Ada  project  is  dependent  on  a  number 
of  factors  such  as  the  orientation  of 
the  method,  the  characteristics  of  the 
project,  the  experience  and  expertise 
of  the  project  personnel,  and  the 
project  management  requirements. 

It  was  important  to  the  author  that 
the  approach  to  be  developed  for 
evaluating  and  selecting  a  method  was 
comprehensive  enough  to  be  useful  in  a 
real-world  environment  and  flexible 
enough  to  be  used  for  a  variety  of 
project  scenarios. 

The  proposed  approach  for  method 
evaluation  and  selection  is  as 
follows: 

Step  1 .  Develop  a  project  profile 
which  describes  the  features  of  the 
project  that  are  important  in  the 
method  selection  process  for  the  Ada 
project. 

Step  2.  Use  the  established  project 
features  to  establish  priorities  and 
weights  for  the  generic  method 
features  that  will  be  used  to  evaluate 
the  candidate  methods.  These  method 


features  are  now  specific  to  the 
particular  Ada  project. 

Step  3.  Set  up  a  checklist  for  use  in 
evaluating  candidate  methods.  The 
checklist  contains  the  prioritized  and 
weighted  method  features  and  provides 
a  quantitative  measure  of  the 
importance  of  each  feature  for  the 
particular  Ada  project. 

Step  4.  Establish  the  criteria  to  be 
used  in  selecting  one  of  the  candidate 
methods  based  on  the  results  of  the 
method  evaluation. 

Step  5.  Select  the  candidate  methods 
that  are  proposed  for  use  on  the  Ada 
project. 

Step  6 .  Evaluate  the  candidate 
methods  based  on  the  prioritised  and 
weighted  method  evaluation  features. 

The  result  of  the  method  evaluation 
process  is  that  each  candidate  method 
will  receive  a  quantitative  rating 
(score)  which  reflects  its  suitability 
for  use  on  the  Ada  project  under 
consideration.  This  information  is 
then  used,  usually  in  conjunction  with 
other  information,  to  select  the 
method  to  be  used. 


5.  ERQJKIJ.RQF.ILE 

The  purpose  of  the  project  profile  is 
to  establish  the  features  of  the  Ada 
project  that  will  have  a  significant 
impact  on  the  selection  of  a  method. 
These  features  are  grouped  into  the 
following  areas: 

*  Application'  characteristics 

*  System  goals/attributes 

*  Project  characteristics 

*  Personnel  characteristics 


A  sample  set  of  these  project  features 
is  supplied  in  Figure  1.  The  sample 
set  can  be  used  as  a  base  from  which 
to  develop  the  set  of  features  that 
reflects  the  specific  needs  and 
concerns  of  the  project  under 
consideration. 

The  Ada  developer  then  decides  which 
features  are  relevant  for  the  project 
and  rates  the  project  features  to 
reflect  the  actual  project 
environment.  An  actual  project 
profile  is  provided  in  Figure  2. 
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6.  METHOD  FEATURES 

One*  the  project  profile  Information 
has  been  specified,  the  next  step  is 
to  use  this  profile  information  to 
establish  the  method  features  which 
are  important  for  the  Ada  project. 

figure  3  contains  a  proposed  set  of 
generic  method  features  that  can  be 
used  as  a  basis  for  evaluating  a 
candidate  method  for  use  on  an  Ada 
project.  This  list  of  features  covers 
a  range  of  issues  to  Include 
methodology  implementation  details, 
project  management,  and  automated 
method  tools.  A  developer  can  add 
issues  to  the  list,  as  required,  to 
provide  a  more  comprehensive  sat  of 
method  evaluation  criteria. 

The  generic  method  features  are  then 
ranked  to  establish  the  relative 
importance  of  the  method  features  for 
the  Ada  project  under  consideration. 
The  project  profile  information  is 
used  to  ensure  that  the  importance  of 
the  method  features  reflects  the 
information  obtained  from  the  project 
profile. 

Figure  4  contains  an  actual  ranking  of 
the  importance  of  selected  method 
features  for  an  Ada  project.  The 
rankings  for  the  method  features 
reflect  the  actual  project  profile 
information  presented  in  Figure  2. 
This  list  or  one  similar  to  it  is  then 
used  to  develop  a  checklist  for 
evaluating  candidate  methodologies. 


7.  HEXHOP-EVALVATIQM 

The  ranking  of  method  features  (Figure 
4)  is  used  to  prepare  a  checklist  for 
use  in  evaluating  the  methods  that  are 
candidates  for  use  on  the  Ada  project. 
Figure  5  contains  an  example  of  an 
actual  checklist  that  was  developed  to 
evaluate  candidate  methods. 

The  result  of  each  evaluation  is  a 
filled-in  checklist  which  provides  an 
individual  rating  of  the  candidate 
method  for  each  method  feature. 
Figure  6  contains  an  example  of  an 
actual  filled-in  checklist  for  an  Ada 
project. 


8.  METHOD  SELECTION  CRITERIA 


The  result  of  the  entire  evaluation 
process  is  a  quantitative  rating 


(score)  for  each  method  that  is 
evaluated.  The  relative  scores  for 
the  different  methods  can  bo  used,  as 
input  for  determining  which  of  the 
candidate  methods  is  most  suitable  for 
use  on  the  Ada  project. 

The  selection  of  a  candidate  method 
can  be  made  according  to  selection 
criteria  that  are  set  up  by  the  Ada 
developer.  For  example,  a  developer 
could  decide  to  throw  out  all  methods 
which  receive  a  score  below  passing 
(such  as  70%).  The  remaining  methods 
could  be  evaluated  based  on  their 
overall  score  and  their  score  on  a 
selected  subset  of  criteria. 


9.  SUMMARY 

The  evaluation  and  selection  of  a 
methodology  for  use  on  an  Ada  project 
is  one  of  the  most  critical  decisions 
that  is  made  during  the  development 
effort.  The  approach  that  was 
presented  here  is  just  one  possible 
approach  that  can  be  used  perform  this 
activity. 

This  approach  provides  a  set  of 
quantitative  and  objective  results 
that  can  be  used  in  conjunction  with 
qualitative  and  subjective  results  to 
evaluate  the  suitability  of  a  method 
for  use  on  an  Ada  project. 

It  should  be  noted  that  the  success  of 
this  method  depends  heavily  on  the 
accuracy  and  completeness  of  the 
project  profile  information  and  the 
method  features. 
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or 

No 

SYSTEM  ATTRIBUTES 


POSSIBLE -RATINGS 


Reliability 

Maintainability 

Tracaability 

Efficiency 

Portability 

Rauaability 

Flexibility 

Verifiability 

Expandability 

Accuracy 

Integrity 

Modularity 


Low,  Medium,  High 
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Low,  Medium,  High 
Low,  Medium,  High 
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PROJECT  CHARACTERISTICS 


POSSIBLE-RATINGS 


Sire  -  LOC 
Sixe  -  Personnel 
Complexity 
Risk 

Development  Time 
Development  Cost 
Project  Visibility 
Use  Of  Automated  Tools 
Training  Budget 
Customer  Influence 


Small,  Medium,  Large 
Small,  Medium,  Large 
Low,  Medium,  High 
Low,  Medium,  High 
Short,  Medium,  Long 
Small,  Medium,  Large 
Low,  Medium,  High 
Low,  Medium,  High 
Small,  Medium,  Large 
Low,  Medium,  High 


PERSONNEL  CHARACTERISTICS 


POSSIBLE  RATINGS 


Work  Experience 
Related  work  Experience 


Low,  Medium,  High 
Low,  Medium,  High 


FIGURE.  2 «  .ACTUAL  PROJECT  PROFILE 

APPLICATION  CHARACTERISTICS  ACTUAL  RATINGS 


Real-Time 

Yes 

Distributed 

Yes 

Concurrency 

Yes 

Mission-Critical 

Yes 

Memory-Critical 

Yes 

Time-Critical 

Yes 
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Secure  System  Yea 
Embedded  Application  Yes 
Data-Oriented  Mo 
Process-Oriented  Yes 


SXSIEK-ATTRIBUIES 


ACTUAL  RATINGS 


Reliability  High 

Maintainability  High 

Traceability  Medium 

Efficiency  High 

Portability  Low 

Reusability  Low 

Flexibility  Medium 

Verifiability  High 

Expandability  Medium 

Accuracy  High 

Integrity  High 

Modularity  Medium 


£&QJ£Cl_CH&RACIERISnC£ 


ACTUAL  RATINGS 


Size  -  LOC 
Size  -  Personnel 
Complexity 
Risk 

Development  Time 
Development  Cost 
Project  Visibility 
Use  Of  Automated  Tools 
Training  Budget 
Customer  Influence 


Medium 

Medium 

High 

High 

Medium 

Medium 

High 

Low 

Small 

Medium 


EERS.QWMEL-CB&S&C1ERISXKS 


ACTUAL  RATINGS 


Work  Experience  Low 

Related  Work  Experience  Low 


EIGWE  3» — GENERIC  METHOD  FEATURES 


TECHNICAL 


IMPORTANCE 


Process  Visibility 

Data  Visibility 

Ada-Oriented 

Information  Hiding 

Program  Structure 

Data  Structure 

Quality  of  Resulting  Design 

Design  Consistency 

Problem  Definition 

Use  For  Large  Projects 


Low,  Medium,  High 
Low,  Medium,  High 
Low,  Medium,  High 
Low,  Medium,  High 
Low,  Medium,  High 
Low,  Medium,  High 
Low,  Medium,  High 
Low,  Medium,  High 
Low,  Medium,  High 
Low,  Medium,  High 


MANAGEMENT 

Maturity  Of  Method 
Ease  Of  Use 
Ease  Of  Learning 
Documentation 


IMPORTANCE 

Low,  Medium,  High 
Low,  Medium,  High 
Low,  Medium,  High 
Low,  Medium,  High 
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Life  Cycle  Model  Flexibility 
Available  Training 
Guidelines  For  Method  Usage 


Low,  Medium,  High 
Low,  Medium,  High 
Low,  Medium,  High 


automated  tools 


JUttgRIABCB 


Availability  Of  Tools 
Cost  Of  Tools 


Low,  Medium,  Hlph 
Low,  Medium,  High 


r.lSUM.i»  ACTUAL  HAWKED  METHOD 
FEATURES 


iecmmical 


IMPORTANCE 


Process  Visibility 

Data  Visibility 

Ada-Oriented 

Information  Hiding 

Program  Structure 

Data  Structure 

Quality  Of  Resulting  Design 

Design  Consistency 

Problem  Definition 

Use  For  Large  Projects 


High 

High 

High 

High 

High 

Medium 

High 

Medium 

Medium 

Medium 


management 


IMPORTANCE 


Maturity  Of  Method 
Rase  Of  Use 
Rase  Of  Learning 
Documentation 

Life  Cycle  Model  Flexibility 
Available  Training 
Guidelines  For  Method  Usage 


High 

High 

High 

Medium 

Low 

Medium 

High 


AUTOMATED  METHQD.TQQL5 

Availability  Of  Tools 
Cost  Of  Tools 


IMPORTANCE 

Low 

Low 


FIGURE . 5 «  SAMPLE  METHQD-EYALUATI OH 

CHECKLIST 


IQD_.f  MATURES 

ERIQRITY 

WEIGHT 

Ada -Oriented 

1 

20% 

Ease  Of  Use 

2 

15% 

Rase  Of  Learning 

3 

15% 

Available  Training 

4 

10% 

Guidelines  For  Method  Usage 

5 

10% 

Quality  Of  Resulting  Design 

6 

7% 

Process  Visibility 

7 

7% 

Information  Hiding 

8 

5% 

Program  Structure 

9 

4% 

Maturity  Of  Method 

10 

3% 

Data  Structure 

11 

2% 

Documentation 

12 

2% 

loot 
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FIGURE  6»  ACTUAL  HETUQP  EVALUATION 

CllECSULSI 


Ada-Oriented 
Eaao  Of  Uao 
Eoao  Of  Looming 
Available  Training 
Guidelines  For  Method  Usage 
Quality  Of  Resulting  Design 
Process  Visibility 
Information  Hiding 
Program  Structure 
Maturity  of  Method 
Data  Structure 
Documentation 


PRIORITY  WEIGHT  SCORE 

1  20%  10% 

2  15%  10% 

3  15%  7% 

4  10%  5% 

5  10%  7% 

6  7%  3% 

7  7%  4% 

8  5%  4% 

9  4%  3% 

10  3%  3% 

11  2%  2% 

12  2%  1% 


100%  59% 
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AN  ADA  DESIGNED  DISTRIBUTED  OPERATING  SYSTEM 


Martin  D.  Sorkin 
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Abstract 

The  design  of  a  throe  level  distributed 
executive  for  an  avionics  system  using 
Ada  *as  a  difficult  undertaking.  It 
required  a  new  understanding  in  the 
approach  to  the  design  of  a  system  as 
well  as  training  r.ot  only  in  the  lan¬ 
guage  but  in  the  entire  approach  to  the 
problem,  object  oriented  design  was  to 
be  used  and  required  a  new  approach  to 
tho  problem.  Personnel  wore  not  train¬ 
ed  in  tho  language  nor  was  management 
prepared  for  such  an  undertaking.  It 
required  perseverance  os  well  as  a 
commitment  on  management  and  personnel 
to  got  rid  or  the  old  approaches  and 
try  the  new. 


Introduction 

In  tho  last  quarter  of  1994  tho  United 
States  Air  Force  requested  from  the 
major  air  frame  manufacturers  a  design 
called  the  Three  Level  Executive, 
these  levels  being  a  Kernel  Executive, 
a  Uistribv  .cd  Executive  and  a  Systems 
Executive.  This  operating  system  was 
to  bo  designed  Gonorically.  For  this 
paper  a  generic  system  is  as  ono  that, 
by  use  of  data  types,  the  configura¬ 
tion  of  hardware,  communications  and 
application  tasks  will  define  to  the 
Kernel  and  Distributed  Executive 
packages  their  operating  environment. 

By  changing  these  types  and  then  re¬ 
compiling  those  packages  the  execu¬ 
tive  is  ready  for  operation.  There 
is  one  modification  to  this  operation. 
It  is  those  portions  of  the  system 
that  are  hardware  dependent  and  must 
change  when  the  host  computer  changes. 
This  will  be  discussed  further  in  this 
paper.  The  operating  system  is  to  be 
input  table  driven  and  these  tables 
would  describe  the  hardware  configura¬ 
tion,  the  communications  network,  the 
necessary  applications,  and  any  other 
pertinent  information  necessary  to  make 
a  functional  operating  system  for  air¬ 
craft  now  and  in  the  future. 


A  briof  explanation  of  this  avionic 
distributed  operating  system  is  neces¬ 
sary  in  order  to  familiarise  tho 
reader  with  tho  terms  in  this  paper. 
The  system  is  dosignod  to  run  cycli¬ 
cally.  By  cyclically  wo  mean  that 
there  is  a  set  major  eyclo,  i.e.,  64 
harts  and  the  major  cycle  is  broken 
down  into  64  minor  cycles  each  of 
length  15.625  milliseconds.  Certain 
tasks  will  be  scheduled  to  run  during 
each  minor  cycle,  every  15.625  milli¬ 
seconds  such  as  tho  Distributed 
Executive  while  other  tasks  can  run 
each  cycle,  every  other  cycle,  onee  a 
major  cycle,  etc.  The  Kernel  and 
Distributed  Executive  are  in  each  pro¬ 
cessor  in  the  system  whilo  tho  Systems 
Executive  and  associated  othor  tasks, 
such  as  tho  Configuration  Manager  will 
be  in  just  two  processors. 


Basic  Design 

Tho  design  i3  rather  complex  in  that 
tho  Executive  can  control  up  to  N 
processors,  up  to  Y  different  busses, 
with  tho  types  of  busses  being  inde¬ 
pendent  of  each  other,  recognise  bus 
errors  and  then  determine  faults,  and 
do  dynamic  relocation  of  those  tasks 
that  arc  affected  by  the  faults  while 
keeping  tho  rost  of  tho  system  opera¬ 
tional  with  a  minimum  of  interference 
to  the  general  operation  of  the  total 
system.  The  following  is  a  brief 
description  of  each  of  tho  three  parts 
of  the  Throe  Level  Distributed  opera¬ 
ting  system. 

Kernel  Executive 

Ada  compilers  come  with  a  runtime 
kernel  and  runtime  system  routines. 

The  supplied  kernel  was  not  appli¬ 
cable  to  our  design  and  required 
extensive  rewriting.  This  included 
a  dcsiyn  of  a  new  linker  for  reasons 
explained  further  in  this  section. 

The  Kernel  is  responsible  for  the 
following  functions: 
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1.  Initial  power-up  testing  of  the 
processor. 

2.  Initialisation  of  the  interrupt 
services  the  nano  used  to  define  the 
10  handier  routines. 

3.  Calling  the  Distributed  Execu¬ 
tive  to  do  the  bus  initialisation. 

4.  Creating  the  task  control  bloeks 
as  tasks  are  loaded  into  their  res¬ 
pective  processors. 

5.  Handling  Ada  exceptions. 

6.  Scheduling  of  Tasks  on  a  cyclic 
basis. 

7.  Maintenance  of  timers,  clocks, 
page  registers,  etc. 

8.  Participating  in  the  recon¬ 
figuration. 

Distributed  Executive 

This  is  the  nano  used  to  dofinc  the  10 
bus  handler.  The  Distributed  Executive, 
hereafter  referred  to  as  the  DE,  has 
the  following  responsibilities: 

A.  During  System  Initialisation 

1.  Duild  the  system  network  by 
seeing  what  processors  and  devices  are 
connected  to  each  bus. 

2.  Load  the  processor  connected 
to  the  System  Mass  Memory,  the  System 
and  Configuration  Manager  applications. 

3.  Read  the  configuration  tables, 
application  load  instructions,  active 
remote  terminal  tobies  and  all  other 
system  tables  off  the  System  Mass 
Memory. 

4.  Send  these  tables  to  all 
other  processors  in  the  system. 

D.  During  System  Running 

1.  As  a  bus  controller,  send  out 
commands  to  do  the  required  input/ 
output  for  each  cycle. 

2.  As  a  remote  processor,  pre¬ 
pare  the  bus  to  receive  or  send  data 
for  the  current  cycle. 

3.  Process  System  Mass  Memory 
requests. 

C.  During  Re-configuration 

1.  Do  the  System  Mass  Memory  10 
to  load  the  processors  with  the  re¬ 
quired  application  tasks. 

2.  Insure  that  the  processors 
not  involved  in  the  re-configuration 
continue  their  cyclic  10. 

3.  Communicate  to  the  Kernel 
when  tasks  arc  deleted  and  when  a  load 
has  been  completed. 

System  Executive 

The  System  Executive  is  a  relocatable 
task  that  works  with  the  Configuration 
Manager  and  the  Maintenance  Monitor  to 
provide  the  following  functions: 


1.  Handles  all  error  reports  and 
passes  them  to  the  Maintenance  Monitor. 
The  Maintenance  Monitor  will  determine 
when  errors  become  faults.  The  Main¬ 
tenance  Monitor  will  not  be  discussed 
in  detail  as  it  is  system  related  and 
will  change  with  each  major  application 
that  uses  this  executive. 

2.  Control  aeecss  to  the  System 
Mass  Memory  on  a  task  priority  basis. 

3.  Gathers  system  status  from  all 
the  processors  and  prepares  data  which 
is  passed  to  the  Maintenance  Monitor 
to  determine  processor  task/bus 
failure. 

Thi3  brief  explanation  should  suffice 
to  give  the  user  a  working  knowledge 
of  the  way  the  system  is  designed. 

The  next  section  will  go  into  a  bin 
more  detail  on  the  design  of  the  two 
executives  that  are  the  moat  sensi¬ 
tive  to  the  multi-processor  environ¬ 
ment. 

Distributed  Executive  Sensitivity 

The  DE,  being  the  controller  of  all 
the  busses  in  the  system,  is  the  most 
sensitive  to  the  multi-processor 
environment.  When  the  Kornol  Execu¬ 
tive,  in  each  of  the  processors, 
finishes  its  initialization,  it 
calls  the  DE  to  determine  the  hard¬ 
ware  configuration  of  the  system 
using  tables  that  are  on  tho  System 
Mass  Memory,  hereafter  called  the  SMM. 
These  tables  are  a  series  of  arrays 
that  contain  tho  complete  description 
of  all  hardware  that  is  on  each  bus, 
tha  bus  configuration  and  bus  types, 

10  channels  and  tho  initial  appli¬ 
cation  load  of  each  of  tho  processors. 

Upon  receiving  control  from  tho  Kornol 
Executive,  tho  DE  will  road  tho  back¬ 
plane  id  of  tho  processor.  The  back¬ 
plane  is  comparod  to  tho  array  that 
contains  tho  backplane  to  processor 
identification.  This  array  also 
specifios  whether  this  processor  is  to 
bo  tho  initial  controller  of  the  SMM 
and  therefore  the  processor  that  will 
contain  tho  primary  System  Executive. 

If  this  is  the  Primary  Processor,  the 
DE  will  now  acquire,  from  tho  SMM,  the 
following  arrays: 

A.  The  hardware  configuration  of 
the  system.  The  DE  will  use  this  array 
to  issue  bus  tests  to  determine  which 
of  the  remote  processors/hardware  is 
responding  to  the  commands  being  issued 
on  the  bus.  A  system  status  table  is 
constructed  to  hold  the  results  of 
these  tests. 
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D.  Tho  array  containing  the  pro¬ 
cessor  to  remote  ternln.il  identifi¬ 
cation  is  acquired.  This  arr*** 
contains  the  renote  identlfic  for 
each  of  the  remote  terminals  to  the 
bus  controller. 

C.  The  message  to  task  array  is 
acquired.  This  array  contains  the 
relationship  between  message  identi¬ 
fication  and  remote  terminal  identi¬ 
fiers.  This  array  is  used  to  pass 
data  between  renote  terminals.  Slnee 
this  is  a  distributed  system  an  appli¬ 
cation  does  not  know  where  another 
application  resides.  Xt  is  the  res¬ 
ponsibility  of  the  OB  to  command  the 
designated  bus  to  send  or  receive  the 
data  required.  The  information  about 
whnt  application  has  commanded  a  road/ 
write  of  a  particular  pieec  of  data  is 
located  in  this  array.  Since  hardware, 
i.o.,  sensors,  radar,  etc.,  ean  not 
issue  these  requests,  this  array  con¬ 
tains  their  identifiers  and  information 
about  when  this  data  is  to  bo  written, 
the  remote  id  of  the  hardware  and 
other  pertinent  information. 

When  the  arrays  are  read  off  the  SHM 
Into  tho  primary  processor,  the  DE  will 
send  all  those  arrays  to  all  other 
processors  that  can  become  the  bus 
controller.  Tho  System  Executive  and 
Configuration  Manager  is  loaded  into 
the  primary  processor.  At  this  point 
a  message  Indicating  that  the  System 
Executive  has  boon  loaded  is  sent  to 
all  othor  processors  In  the  system.  At 
this  point  control  is  returned  to  tho 
Kernel  Executive. 

During  primary  processor  initialisation 
the  other  processors  arc  waiting  for 
the  load  of  the  configuration  arrays 
and  the  nessago  that  indicates  that  tho 
System  Executive  has  been  loaded.  Xf 
this  message  is  not  received,  another 
processor  will  become  the  primary  pro¬ 
cessor,  based  on  a  series  of  parameters 
and  timo  calculations,  and  perform  tho 
services  described  abovo.  Onco  tho 
configuration  tables  have  been  received, 
tho  other  processors  will  bo  waiting 
for  application  load  messages  and 
finally  the  Initialization  Complete 
message.  Once  the  Initialization 
Complete  message  has  been  received,  the 
entire  system  is  put  in  a  system  run¬ 
ning  state. 

Each  application,  on  initialization, 
will  call  the  DE  via  a  Kernel  call  and 
will  register  its  cyclic  Input/Output 
requests.  This  request  will  contain 
all  necessary  information  about  the 
data  to  be  sent  or  received.  It  will 
also  contain  the  cycle  period  when  the 
data  is  to  be  sent/ received,  the 


number  of  words  in  tho  Xnput/Ontpuc 
area  and  othor  necessary  information. 
These  requests  are  processed  by  the  DE 
and  tho  cyclic  10  tables  are  built  for 
each  of  tho  cycles  in  the  system. 

The  Xnpue/Output  task  of  the  OK  Is 
scheduled  every  C-t  hertz.  It  win  do 
all  neeessary  processing  to  creato  the 
Input/Output  commands  for  this  cycle. 
Once  the  10  chain  is  built,  the  DE  will 
issue  the  commands  to  the  physical  bus 
hardware  to  start  the  10  chain.  When 
errors  are  detected  by  the  Interrupt 
Service  routine  of  the  DE,  these  are 
roported  to  tho  Maintenance  Monitor. 

The  DE  will  not  re-dlrect  Input/Output 
or  declare  any  device  inopcratlvo. 

This  is  done  only  undor  direction  of 
the  Configuration  Monitor.  Each 
cycle,  the  DE  will  interrogate  each 
processor  to  seo  if  any  application 
has  requested  any  sosvices.  This  is 
done  by  each  of  tho  bus  mastors  and 
will  differ  with  the  type  of  bus, 

1SS3B,  High  Speed  data  busses,  etc. 

System  Executive  Sensitivity 

There  are  two  System  Executives  always 
live  in  the  system,  the  Primary  which 
will  receive  data  and  write  data  and 
the  stand-by  which  just  recoivos  data. 
If  the  processor  containing  the  Primary 
System  Executive  should  fail,  the 
stand-by  will  assume  control  and  will 
send  a  message  to  tho  Configuration 
Monitor  that  a  relocation  should  take 
placo.  Since  the  System  Executive 
controls  access  to  the  SMM,  it  is 
important  that  there  always  be  an 
active  System  Executive  and  along  with 
it  tho  Configuration  Managor. 

Tho  design  of  tho  System  Executive  and 
Configuration  Manager  is  open-ended 
since  these  tasks  arc  more  dependent 
of  tho  type  of  system,  fighter,  trans¬ 
port,  space  flight,  etc.,  then  the 
Kornel  and  DE  who  arc  dependent  of  the 
hardware. 

Doslon  Configuration 

In  order  to  design  the  system,  an  ideal 
configuration  of  hardware  was  desig¬ 
nated.  This  configuration  consisted 
of  the  following  equipment: 

1.  Eight  1750s  designated  as  Mission 
Data  Processors,  each  containing  one 
million  words  of  storage. 

2.  Four  1750s  designated  as  Vehicle 
Data  Processors. 

3.  A  Common  Signal  Processor  to 
collect  the  data  from  the  sensors  which 
were  connected  to  1553B  busses  and  send 
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this  data  over  the  designated  Mission 
and  Vehicle  busses. 

4.  Three  dual  redundant  hioh  speed 
data  busses;  one  pair  allecatau  the 
5MM  busses;  one  pair  allocated  as  the 
Mission  Data  Processor  communication 
path  and  the  last  pair  for  mission  to 
vehicle  data  processing  communica¬ 
tions. 

5.  A  quad-redundant  set  of  high 
speed  data  busses  for  communications 
between  the  Vehicle  Data  processors 
which  were  used  for  voting  purposes. 

Our  design  was  based  on  this  configu¬ 
ration.  when  i&plcsentatlcn  of  the 
ssytem  was  started  this  configuration 
did  not  exist.  We  were  forced  to  re¬ 
design  the  system;  to  a  somewhat  scaled 
down  configuration  which  consisted  of 
the  following: 

1.  Two  1750  mission  data  processors 
with  64k  of  storage,  connected  via  a 
15S3  data  bus. 

2.  A  VAX  780  simulating  sensor  data 
communicating  over  a  1553  bus. 

3.  A  Harris  computor  simulating  the 
cockpit  displays,  also  over  a  1S53  bus. 

This  configuration  caused  much  re¬ 
thinking  in  tho  DE  and  made  our  original 
design  somewhat  impossible  to  carry 
out.  We  had  no  off-line  processor  to 
build  the  configuration  tables  and  this 
had  to  be  simulated  and  because  of 
memory  requirements  much  of  tho  generic 
executive  had  to  be  eliminated. 


ADA  Implementation 

How  chat  a  brief  and  Z  hope  not  too 
boring  description  of  the  Three  Level 
Executive  has  been  presented,  wo  will 
discuss  tho  use  of  Ada  and  its  bene¬ 
fits  and  problems,  which  Z  am  sure  most 
of  those  reading  this  paper,  and  I  hope 
thore  arQ  many,  want  to  know  how  Ada 
was  applied  to  this  subject.  Ada  was 
chosen  as  tho  language  of  implemen¬ 
tation  sinco  tho  Department  of  Dofenso 
has  decreed  this  is  tho  High  Order 
Language  of  Choice.  This  was  decreed 
by  the  Advanced  Avionics  System  which 
was  the  original  contract  that  was  lot 
to  design  this  executive.  Tho  other 
reason  for  chosing  Ada  is  described  by 
Mr.  Grady  Booch  in  his  book  "Software 
Engineering  with  Ada"  and  lot  mo 
quote: 

"Ada  is  more  than  just  another  pro¬ 
gramming  language,  however.  Along  with 
the  Ada  Programming  Support  Environ¬ 
ment,  it  represents  a  vary  powerful 
tool  to  help  us  understand  problems  and 


express  their  solutions  in  a  manner 
that  directly  reflects  the  multidimen¬ 
sional  real  world." 

Since  Ada  and  Ada  compilers  for  mili¬ 
tary  computers,  mainly  tho  17S0A,  which 
was  our  target  computer,  were  not  many 
in  number  nor  was  there  many  available 
trained  personnel,  we  first  had  to  come 
up  with  an  approach  which  would  mako 
use  of  the  best  parts  of  Ada,  direet 
all  design  to  be  object  oriented  and 
avoid,  at  all  possible  cost,  ADATRAM 
design.  By  ADATRAM  is  meant  the  design 
of  a  global  database,  all  applications 
sharing  common  data,  tasks  communica¬ 
ting  among  themselves  without  going 
through  the  executives,  and  all  other 
bad  techniques  that  we  as  an  industry 
have  used  over  the  years.  In  other 
words  we  did  not  want  to  make  the  mis¬ 
takes  of  old.  The  system  had  to  be 
easy  to  maintain,  and  bo  as  modular  as 
possible. 

Education  of  Management  and  Staff 

The  following  is  an  outline  of  our 
approach  to  training  management  as  well 
as  the  current  staff  in  using  Ada  and 
implementing  tho  design  method  called 
Object  Oriented  Design. 

In  the  great  and  old  days,  systems  were 
designed  where  applications  had  free 
reign  to  pass  data  directly  from  one 
application  to  another.  Programs  wore 
designed  to  fit  in  a  singlo  computor 
and  there  was  no  need  for  a  different 
approach.  Just  store  it  in  a  common 
area  and  everyone  and  his  brother  could 
get  a  look  at  it  and  possibly  destroy, 
or  modify  tho  data.  This  executive  had 
to  insure  data  reliability  and  integ¬ 
rity.  This  hurdle  was  one  of  tho  most 
difficult  to  overcome  in  our  retraining 
of  management  and  staff.  This  is  a 
distributed  system  and  we  had  to  ins¬ 
till  into  the  applications  and  system 
engineering  staffs  that  unless  there 
was  a  shown  need,  no  applications  could 
bo  guaranteed  to  rcsido  in  the  3nne 
processor. 

Again  to  digress,  before  Ada,  systems 
engineering  was  done  for  a  project  with 
little  or  no  regard  to  the  language  to 
be  used  because  it  did  not  affect  the 
operations  of  design,  coding,  pro¬ 
gramming  or  documentation.  If  some  of 
it  was  in  JOVIAL,  some  in  Fortran,  a 
little  in  C,  a  bit  more  in  assembler, 
so  what.  This  entire  approach  to  the 
design  of  a  project  had  to  be  changed. 
The  software  system  had  to  be  designed 
with  the  capabilities  of  Ada  and  its 
constraints  and  viewed  in  its  entirety 
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with  each  object,  radar  application, 
Nav,  etc.,  being  designed  as  a  self- 
contained  package  with  the  data  pas¬ 
sages  being  the  weans  of  communication 
between  other  applications. 

He  now  had  to  take  a  software  engi¬ 
neering  approach  to  the  problem  and 
think  a  bit  differently.  Each  object, 
that  is  for  example  a  Navigation 
system,  a  weapons  system,  a  sensor 
system,  ete.,  was  to  be  designed  as 
packages.  These  packages  did  not  have 
to  cake  into  account  where  other  appli¬ 
cations  resided.  Bach  package  was  to 
be  designed  without  regard  to  the 
other  packages  nor  worry  about  the 
common  areas  for  data  passage.  There 
was  to  be  little  or  no  shared  data. 

All  Information  is  to  be  passed  via  the 
DB  and  the  DB  has  the  responsibility  to 
get  the  information  to  the  correct 
apollcation  data  area.  Obviously  input 
and  output  interfaces  still  existed  but 
data  was  not  to  be  directly  placed  in 
any  common  area  except  for  system  re¬ 
lated  data.  See,  there  is  always  an 
exception  to  the  rule.  All  parameters 
had  to  be  typod  and  all  limits  to 
arrays,  rangos  and  any  other  types  that 
were  greator  than  1  in  length  wore  to 
be  parameterized. 

Zt  sounds  simple  but  people  just  want 
to  do  it  the  old  tried  and  true  way. 

The  usual  argument  we  meet  was  "hey, 

I  know  the  array  is  1  to  10  items  so 
why  not  define  it  that  way.  It's 
easier  to  read  then  some  silly  object 
'first  to  object'  last."  Maybe  easier 
to  read  but  hardor  to  maintain,  change 
and  if  more  than  one  procedure  uses  the 
array  how  do  wo  insure  the  same  ranges. 
People  consistently  tried  to  avoid 
using  tho  Ada  language  to  its  full 
extent. 

The  toughost  problem  was  the  instilling 
in  tho  group  that  Ada  was  to  bo  viewed 
in  a  Software  Systems  Approach.  This 
meant  that  from  the  very  beginning  of 
a  project,  all  design  starting  with 
the  system  requirements,  must  be 
viewed  in  tho  totality  of  tho  Ada 
language.  All  documentation  had  to  be 
prepared  with  the  constraints  os 
applied  to  Ada.  As  is  standard,  in 
the  government's  wisdom,  the  documen¬ 
tation  hod  to  be  done  to  Military 
Standard  2167  which  is  not  too  well 
defined  for  the  Ada  language.  Second, 
most  of  the  personnel  hod  never  seen 
Ada,  let  alone  the  rigid  typing  and 
packaging  that  we  were  trying  to  get 
implemented.  The  system  requirements 
hod  to  be  done  before  detailed  design 
could  begin  so  we  used  Mil-Standard 


490  which  permitted  us  more  leeway  in 
designing  the  documents. 

All  the  personnel  working  on  the  pro¬ 
ject  except  for  a  few  had  never  heard 
of,  let  alone  worked  in,  any  environ¬ 
ment  where  one  had  to  view  each  object, 
Radar,  sensors,  Kernel,  DB,  as  a  pack¬ 
age  with  data  that  can  be  viewed  by 
only  those  who  must  have  access.  This 
packaging  of  related  procedures  for  a 
specific  object  was  loosely  used  in 
other  projects  but  had  to  be  enforced 
by  other  means  than  the  language  it¬ 
self.  For  an  Ada  system  this  was 
tightly  controlled  with  the  use  of  vis¬ 
ibility.  No  application  could  "with" 
a  Spec  unless  that  Spec  was  part  of 
its  own  package.  A  portion  of  the 
Kernel  which  is  used  by  all  applica¬ 
tions  to  communicate  with  the  opera¬ 
ting  system  is  also  "withesd".  This  is 
being  eliminated  with  the  implementa¬ 
tion  of  a  BEX  call  which  is  explained 
later  in  this  paper.  Now  that  wo  hid 
our  design  specified,  our  system 
engineering  specification  clarified, 
our  coding  standards  specified,  we 
were  ready  to  go.  How  long  could  It 
take  to  learn  Ada  and  get  this  execu¬ 
tive  on  the  road?  The  staff  was 
still  untrained  and  what  training 
problems  could  we  encounter?  Ke  were 
all  professionals. 


Learning  Ada 

Our  environment  consisted  of  our  target 
computers,  Mil-Standard  machines  1750As 
and  there  were  threo  systems  just 
waiting  in  the  lab  to  be  used.  The 
VAX1  system  was  our  host  computer  and 
it  contained  an  Ada  compiler.  Manage¬ 
ment  figured  that  Ada  was  like  any 
other  language  and  allowed  forty  hours 
of  training  to  got  those  who  were  un¬ 
familiar  with  the  languages  up  to  spaed. 
This  was  a  gross  undorostimato  of  time. 
I  would  say  that  based  on  our  experi¬ 
ence  with  Ada,  one  should  allow  about 
400  hours  of  training  with  active  lab 
practice  to  have  a  person  learn  all 
the  intricacies  of  the  language.  The 
group  being  trained  had  an  average  of 
over  10  years  of  experience  with  many 
languages  so  use  this  as  a  guide. 

Since  we  could  not  convince  our  manage¬ 
ment  that  the  time  allowed  was  too 
small  we  just  pushed  ahead  and  de¬ 
signed,  coded  and  tested  out  the  execu¬ 
tive  as  we  learned.  If  there  was  a 
space  and  I  could  list  the  programs 
developed  on  our  first  attempt  one 
would  notice  that  we  had  produced 
Adatran  in  our  code,  all  the  design 
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and  system  engineering  we  painstaking 
laid  out  was  violated  and  the  system 
ran  but  not  as  generieally  as  va 
wished.  Host  of  this  was  attributable 
to  the  tine  constraint  placed  upon  us 
to  demonstrate  a  cycling  system  for 
upper  management.  Most  of  the  code  was 
HARDCODED  to  fulfill  the  requirements 
of  the  demo. 

The  breaking  of  bad  habits  was  prob¬ 
ably  our  toughest  hurdle  to  get  over. 
That  is  besides  trying  to  learn  the 
language.  The  Mil-Standard  815  Ada 
description  was  so  clear  that  almost 
anybody  could  Just  read  the  text  and 
become  an  Ada  export.  It  Just  so 
happened  that  our  staff  probably  had 
learning  disabilities  and  found  the 
text  somewhat  difficult  to  grasp  on 
a  first  reading.  The  entire  staff  went 
out  and  bought  a  book  written  by  Mr. 
Crady  Booch,  "Software  Engineering  with 
Ada"  2  and  used  this  text  along  with 
the  Ada  standard  and  this  improved  the 
learning  curve  tremendously. 

ThQ  second  problem  to  overcome  was  the 
idea  of  a  distributed  system.  Most  of 
the  staff  had  not  had  experience  with 
a  distributed  system.  Thoy  wanted  to 
use  the  global  database,  or  compool 
structure  and  have  tasks  communicate 
directly  with  eaeh  other  through  shored 
memory  areas.  Thoy  also  were  not  used 
to  strict  typing  of  items  and  tried  to 
avoid  this  at  all  cost.  A  special  pro¬ 
blem  existed  for  the  Kcrnol  and  DE 
which *was  the  use  of  Chapter  13  and  all 
it  inplios.  Since  this  was  compiler 
manufacturer  dependent,  VAX  Ada  and  our 
Ada  for  the  1750s  wero  not  too  compat¬ 
ible.  This  caused  and  is  still  causing 
a  problem  in  our  development.  More  on 
this  lator. 

The  system  was  developed  with  a  com¬ 
munication  method,  implemented  in  the 
OE,  that  allowed  tho  application  tasks 
to  request  the  sending  and  receiving 
of  messages.  The  DE  would  take  care 
of  placing  tho  data  into  the  usor 
specified  data  area  or  send  the  data 
from  the  specified  matter  to  or  from 
thu  specified  matter  to  or  from  the 
appropriate  processor.  Easy  to  lay 
down  the  rules,  hard  to  got  people  to 
follow.  A  module  was  developed  into 
which  all  our  data  types  and  message 
formats  were  described.  All  of  a 
sudden,  this  module  was  growing  with 
objects  that  were  visible  to  the  world. 
A  quick  stop  was  put  to  this  and  was 
placed  under  executive  control  to 
limit  the  amount  of  visible  objects  to 
the  entire  environment.  We  had  to 
make  the  Kernel  Executive  have  several 
specs  consisting  of  tho  specifications 


available  for  the  application  tasks, 
a  specification  for  tho  OE  and  t.  •; 
Kernel* 9  private  specification.  This 
came  about  because  of  problems  with 
the  private  pragma  not  working  and 
some  other  compiler  problems. 

After  a  period  of  time  we  considered 
ourselves  an  Ada  trained  Ada  expert 
group,  out  where  was  our  compiler  for 
the  target  machines? 

Ada  Selection  and  Ada  Tools 

To  refresh  the  reader's  memory,  this 
project  started  in  the  latter  part  of 
1985  and  there  were  not  many  Ada 
compilers  available,  let  alone  those 
that  were  certi'ied  by  the  Department 
of  Defense  and  had  the  17S0  as  a  target 
computer.  A  group  of  analysts  was 
selected  to  go  out  and  test  those 
compilers.  They  wero  compared  on  the 
following  criteria: 

1.  Dod  Certified. 

2.  compile  time  based  on  a  speci¬ 
fied  sot  of  progvams  selected  from  the 
Dais  mix. 

3.  Optimisation  capabilities. 

4.  Available  support  from  tho 
supplier. 

5.  Release  of  the  source  code  for 
the  Kernel  and  run-time  support 
packages. 

6.  Cost  and  maintenance  of  the 
compiler. 

7.  Must  bo  able  to  run  on  the  VAX 
and  produce  175QA  object  code. 

8.  Manufacturer  supplied  linker 
with  tho  capabilities  that  were  re¬ 
quired  for  our  executive. 

9.  Tho  compiler  with  tho  least  known 
bugs  at  tho  time  of  selection. 

10.  Debugging  tools  available  along 
with  any  simulator  that  would  run  on 
the  VAX  and  simulate  tho  1750  com¬ 
puters. 

11.  Chapter  13  implementation.  What 
extras  were  available  and  how  were 
they  implemented.  The*  executives  had 
to  use  much  of  tho  Chnptor  13  options 
and  oven  though  these  arc  kept  to  a 
minimum,  tho  implementation  of  those 
options  were  of  great  importance  to 
the  selection  of  the  compiler. 

Tho  process  wont  on  for  four  months  and 
we  finally  selected  our  compiler.  I  do 
not  wish  to  specify  the  name  of  the 
corporation  or  those  compilers  that 
were  selected  since  the  testing  was 
done  over  three  years  ago  and  I  am 
sure  that  the  ones  not  selected  have 
improved  and  I  feel  that  it  would  be 
unfair  to  the  others  now. 
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When  vc  received  our  compiler,  one  of 
the  staff  had  to  cake  the  Kernel  and 
the  supplied  linker  and  make  our 
changes  eo  the  code.  This  cask  was  not 
simple  and  cook  slightly  longer  than 
expected.  The  changes  were  made  over  a 
period  of  cine  with  work  still  being 
done. 

As  we  started  to  earry  out  our  design, 
one  found  that  such  of  the  features 
that  sake  Ada  a  language  which  embodies 
such  of  the  nodern  software  develop¬ 
ment  principles  but  also  rigidly  en¬ 
forces  then  just  was  not  yet  imple¬ 
mented  into  the  cospiler.  In  our 
first  delivered  cospiler  represen¬ 
tation  clauses  did  not  work.  This 
would  have  been  somewhat  acceptable 
for  most  applications,  but  all  the  10 
commands  that  had  to  bo  generated  re¬ 
quired  bit  manipulation  and  without 
it  masses  of  memory  was  used.  Packing 
also  was  not  yet  implemented  and 
strings  were  a  pain  and  were  avoided 
if  at  all  possible.  The  next  non- 
implcmcnted  feature  was  Machine  Inter¬ 
face,  again  a  problem  not  only  for  the 
DC  but  for  the  Kernel  Executive.  We 
had  decided  from  the  beginning  to 
attempt  to  use  little  or  no  17S0 
assembly  packages.  Xn  the  beginning 
not  possible.  At  present  a  new  de¬ 
livery  of  the  compiler  contains  theso 
features  and  we  are  implementing  the 
changes  as  I  write  this  paper. 

Of  course  we  found  compiler  bugs,  which 
is  expected  as  one  trios  to  use  as  many 
of  the  features  of  Ada  and  its  con¬ 
structs  as  possible.  Why  you  ask, 
bccausQ  wc  were  attempting  to  become 
Ada  experts  and  to  do  this  you  try 
everything  in  the  book,  wouldn't  you? 

Our  next  implementation  problem  was  the 
linker.  Since  we  had  to  be  able  to 
load  many  application  tasks  and  each 
task  loaded  had  to  bo  memory  pro¬ 
tected  from  the  other  tasks,  the  linker 
had  to  be  changed  to  implement  tho  page 
register  scheme  available  in  the  1750s. 
At  present  our  linker  will  separate 
operand  from  instruction  to  take 
advantage  of  the  page  register  system 
in  the  1750s,  and  we  are  now  trying  to 
install  the  BEX  linkage  for  appli¬ 
cations  to  communicate  to  tho  execu¬ 
tives  instead  of  a  call. 

For  those  unfamiliar  with  the  1750 
architecture,  the  machine  has  a  series 
of  page  registers  that  permit  the 
operand  and  instructions  to  be  separ¬ 
ated  and  protected  on  a  page  boundary. 

A  page  boundary  consists  of  4096  16 
bit  words.  Each  application  is  per¬ 
mitted  to  have  as  much  as  64k  of 


operand  thnv  it  can  access  and  a  simi¬ 
lar  amount  of  instruction  space.  The 
BEX  linkage  is  an  executive  call  which 
eauses  an  interrupt  which  is  processed 
by  the  Kernel.  With  the  implemen¬ 
tation  of  this  to  tho  Kernel  Executive, 
those  pages  containing  the  executive 
will  no  longer  be  visible  to  the  user. 
This  would  permit  the  application  to 
have  the  full  use  of  the  paged  memory 
available. 

The  simulator  received  with  the  com¬ 
piler  did  not  quite  meet  our  needs. 

A  1750  simulator  was  developed  to  run 
on  the  VAX  host  using  the  output  of 
the  modified  linker.  This  worked  well 
and  still  does  for  the  testing  of 
applications  tasks  but  for  the  Kernel 
and  DE  very  limited  testing  could  be 
done.  We  were  forced  to  do  our 
testing  on  the  1750s. 

As  expected  there  were  very  little 
tools  available  for  the  testing  of  Ada 
generated  code  for  the  1750  computers. 

A  simple  debuggor  with  very  limited 
capabilities  existed  and  the  debugging 
time  greatly  exceeded  our  time  esti¬ 
mates.  When  wc  '.nally  were  able  to 
test,  one  found  the  usual  number  of 
compiler  bugs  which  then  caused  tho 
programmers  to  start  blaming  every  bug 
on  the  compiler.  Is  not  human  nature 
so  predictable?  Clve  a  programmer  a 
straw  and  they  will  make  it  into  a 
giant  oak.  As  a  generic  system  that 
is  being  funded  from  IR  (  D  funds  our 
budgots  wore  not  high  nor  our  equip¬ 
ment  the  best.  The  programmers  did 
have  a  little  bit  to  complain  about. 

Sovcral  demonstrations  were  given  to 
management  and  lo  and  behold  a  real 
three  level  executive  was  being  de¬ 
veloped  and  tasted  on  a  limited  number 
of  computers  using  several  busses. 

The  idea  of  a  DE  written  in  Ada  and 
running  on  Mil-Standard  equipment  was 
fuJ,ly  available  now  for  practical  use. 

Implementation  of  the  Final  Three  Level 
Executive 

Tho  corporation  was  now  convinced  that 
the  project  could  be  done.  No  more 
demo  systems  had  to  be  developed  to 
prove  that  the  design  and  specifi¬ 
cations  could  be  met.  The  old  1750s 
disappeared  and  new  equipment  with 
real  debugging  consoles,  appeared. 
Funding  was  approved  to  make  this 
executive  a  truly  generic  system.  The 
old  adage  comes  true  again,  there  never 
is  enough  time  or  money  to  do  it  right 
the  first  time  but  there  is  always  time 
and  money  to  do  it  over. 
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Currently  the  staff  is  producing  a 
truly  generic  system.  Xt  is  table 
driven  so  that  the  number  of  pro¬ 
cessors,  busses  and  bus  types,  and 
reconfigurability  is  regulated  and  can 
be  changed  by  simply  changing  the 
parameters,  recompiling  and  oft  we  go 
with  maybe  a  little  testing.  The  Three 
Level  Executive  is  now  running  on  a 
three  processor  tvstem.  Xt  is  being 
modified  for  us 
tract  involving 
busses  and  a  lai 
The  busses  being 
1553B. 


a  government  con- 
e  processors,  four 
vumber  of  sensors, 
/d  are  Mil-Standard 


To  add  different  types  of  bussos,  the 
system  allows  the  insertion  e /  that  bus 
handler  with  a  minimum  of  changes.  The 
D£  checks  the  bur/  type  that  Is  to  be 
used  and  will  call  the  appropriate  bus 
package  based  or.  that  type.  As  bus 
types  are  >*dded,  the  bus  package  will 
have  to  be  debugger  but  this  does  not 
affect  any  other  rockagos  in  tho 
system. 

Projectizing  the  Executive 


In  the  latter  part  of  1987,  the  organi¬ 
zation  that  X  am  contracting  with  was 
rewarded  a  contract  to  supply  tho  soft¬ 
ware  for  a  retro-fit  of  an  existing 
airplane  for  the  Air  Force.  Our 
executive  has  boon  chosen  to  be  used  in 
this  project  and  is  also  being  proposed 
for  a  variety  of  systems  being  imple¬ 
mented  or  planned  for  in  the  future. 

The  immediate  project  should  bo  dis¬ 
cussed,  though  somowhat  briefly  as  this 
paper  is  getting  too  long.  Upper 
management,  in  its  groat  wisdom,  de¬ 
creed  that  the  Three  Level  Executive 
bo  usod  in  a  project  just  won  by  the 
company.  Without  consulting  any  of 
the  Executive  group,  the  work  began. 

The  people  on  the  project  wore  not  Ada 
trained,  had  no  knowledge  of  object 
oriented  design  and  thought  a  package 
was  something  you  brought  home  from 
the  store.  The  systems  and  tho  opera¬ 
tional  flight  software  personnel  had 
no  knowledge  of  our  system  but  pre¬ 
pared  the  design  of  all  the  software 
without  any  working  knowledge  of  tho 
operation  executive. 

As  you  can  guess,  they  designed  a 
complete  ADATRAN  system,  with  naming 
conventions,  shared  databases,  dis¬ 
regard  for  relocation  and  all  other 
things  this  executive  expected  to  bo 
used.  As  one  can  surmise,  all  the 
problems  that  the  executive  group  went 
through  during  design  and  implemen¬ 
tation  is  now  going  on  once  more. 


The  new  project  was  designed  without 
regard  for  the  Ada  language  and  there¬ 
fore  is  having  difficulty  in  adapting 
to  our  executive.  The  Air  Force  re¬ 
quired  document  specification  Mil 
Standard  2167  does  not  in  any  shape  or 
form  allow  you  to  document  Ada  pack¬ 
ages  as  one  should.  Xt  is  still 
designed  to  JOVIAL  with  all  its  faults 
and  difficulty  to  read.  For  example, 
wo  had  to  re-write  our  detailed  design 
to  conform  to  2167  and  tho  document 
was  over  2000  pages  in  length.  This 
might  be  all  right  for  a  lifting  exer¬ 
cise  but  as  a  reference  document  it 
is  almost  useless. 

The  Executive  Group  is  now  working  with 
the  project  to  try  to  retrofit  our 
executive  into  their  design.  The  best 
analogy  X  can  think  of  is  when  a  large 
car  manufacture  saw  a  need  for  diesel 
onglnes  for  their  cars,  instoad  of 
designing  a  now  ongino  they  just  took 
their  gas  and  made  it  into  a  diesel. 

X  am  sure  we  all  remember  the  results 
of  that  fiasco.  As  of  tho  writing  of 
this  paper,  wo  are  still  battling  tho 
hard-liners  who  want„global  databases, 
event-driven  10  and  all  tho  Adatran 
chat  you  could  possibly  implement. 

The  configuration  for  tho  project  con¬ 
sists  of  tho  following: 

1.  Five  1750  computers  connected 
via  4  1553  bussos. 

2.  Soqsora  connected  to  the  1750s 
via  1553  busses. 

3.  One  of  tho  1750s  will  use  memory 
as  tho  SMM. 

The  training  goes  on  as  well  as  the 
instilling  of  Object  Orionted  design 
in  all  personnel  working  on  tho  pro¬ 
ject.  Management  is  coming  around  to 
the  idea  of  software  engineering  and 
control  and  the  strength  of  the  Ado 
language  in  controlling  a  project. 
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I.  Abstract 

This  paper  describes  a  Parallel  and  Real-Time 
Simulator  (PARSIM)  which  war  developed  in  Ada  using 
the  Meridian  compiler  on  an  ATAT  PC  6310.  PARSIM, 
developed  an  a  software  tool,  uses  a  Petri  net  model  for 
simulation  of  corcurrcnt  computational  algorithms.  The 
paper  discusses  the  structure  and  operational  characteristic* 
of  PARSIM. 


2.  Introduction 

The  study  and  analysis  of  real-time  and  parallel 
systems  Is  an  active  and  important  area  of  computer  sci¬ 
ence.  An  important  tool  for  such  studies  Is  die  Petri  net 
(Peterson,  Cherry).  A  Petri  net  is  a  particular  type  of 
graphical  model  which  is  especially  suited  for  the 
representation  of  concurrent  and  parallel  systems.  In  this 
paper  we  itpart  on  a  Petri  net  based  Parallel  and  Real- 
Time  Simulator  (PARSIM)  which  was  developed  using 
the  Meridian  Ada  compiler  on  an  ATAT  PC  6310,  whieh 
is  based  on  the  INTEL  20266  microprocessor  and  which 
uses  MS-DOS.  The  paper  consists  of  3  major  parts.  First 
we  briefly  describe  Petri  nets,  the  tool  for  modeling  sys¬ 
tems;  nest  we  outline  PARSIM,  iu  components,  parame¬ 
ters,  and  the  rules  for  elocution;  finally,  we  discuss  results 
on  the  execution  effectiveness  of  PARSIM , 


3.  Description  of  the  Petri  net  model 

A  Petri  net  is  a  special  type  of  directed  graph  con¬ 
sisting  of  nodes,  transitions,  and  arts.  Symbolically  nodes 
(also  called  places)  are  represented  by  circles,  transitions 
by  vertical  bars,  and  the  flow  in  the  graph  by  directed 
arcs,  in  addition,  Petri  nets  use  tokens,  indicated  by  dots 
in  the  nodes,  to  control  the  execution  of  the  network. 


Execution  of  a  Petri  net  may  be  described  by  indicating 
the  state  of  the  network  as  a  function  of  time.  A  con¬ 
venient  way  of  defining  the  state  of  a  given  net  at  a  partic¬ 
ular  time  Is  to  describe  the  number  of  tokens  In  each  place 
at  that  time.  Changes  In  state  arc  controlled  by  the  distri¬ 
bution  of  tokens  In  the  net  State  changes  occur  as  a 
result  of  firings  of  transitions.  When  a  transition  fires, 
there  it  a  redistribution  of  the  tokens  associated  with  its 
input  and  output  places.  A  node  with  an  arc  directed  into 
a  transition  is  defined  as  input  place  for  that  transition; 
whereas  in  output  place  is  defined  as  one  with  an  arc 
directed  from  the  transition  to  that  place.  A  transition  can 
fire  (  be  enabled)  when  each  of  Its  input  places  has  at  least 
one  token  for  each  arc  directed  from  that  place  Into  the 
transition.  A  transition  fires  by  redistributing  the  tokens 
smong  the  places  as  follows: 

One  token  Is  removed  from  an  Input  place  for 
each  are  between  that  input  place  and  the  transition ; 

One  token  Is  creucd  and  deposited  into  each  out¬ 
put  place  for  each  arc  from  the  transition  into  the  place. 

Figure  la  and  lb  Illustrate  the  result  of  the  firing 
of  transition  tj,  For  this  particular  ik:  we  have  four  transi¬ 
tions  and  sis  places.  The  initial  state  is'givcn  by. 
(l.l.0.:,0.0) 

where  the  / *  entry  In  the  six-tuple  represents  the  number 
of  tokens  In  ihc  /**  place.  After  transition  ij  is  fired  die 
new  state  vector  is  given  by 
(0.2. 0.0, 1.0). 

The  time  associated  with  the  firing  of  a  transition  is 
assumed  to  be  aero  within  the  class  of  ’  Untimed  Petri 
Nets’  (see  IPetersoo)).  Also  for  this  class  of  nets,  die 
sequence  of  firings  of  the  transitions  is  random;  i.e.,  a 
given  transition  may  fire  whenever  it  becomes  enabled; 
however,  it  is  further  assumed  that  the  probability  of  two 
transitions  firing  at  the  same  time  is  zero.  A  useful 
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duracteriraiion  for  a  Petri  ik(  an)  a  given  initial  wk 
vector  U  the  teachability  act  This  act  defines  all  the  Hater 
which  can  rcluH  from  any  sequence  of  transition  firings 
starting  from  the  initial  Mate.  Algorithm*  exist  for  the 
construction  of  the  reachability  tree,  which  fat  a  graphical 
representation  of  the  reachability  set  (see  | Peterson,  lloHI- 
day  A  Vernon)), 


4.  The  Structure  of  PARSIM 

The  Petri  net  is  a  natural  tool  for  the  modeling  of 
concurrent  systems  .  The  correspondence  between  the 
simulation  model  and  Petri  nets  it  as  follows.  PARSIM  Is 
a  discrete  event  simulator.  That  is,  k  is  hated  on  a  model 
of  discrete  processes  .  For  our  purposes,  a  process  is  an 
activity  which  executes  or  proceeds  over  time  having  a 
well  defined  beginning  and  end.  Since  each  of  the  transi¬ 
tions  represents  a  process  in  the  simulation,  we  introduce 
the  idea  of  lime  associated  with  die  transition  firing  dura¬ 
tion.  The  initiation  and  conclusion  of  processes  (transition 
firings)  define  events  in  this  model.  Events  change  the 
state;  i.e.,  the  distribution  of  the  tokens  fat  the  net  Recall 
that  places  and  transitions  arc  Petri  net  primitives.  We 
will  be  concerned  with  a  particular  interpretation  of  die 
ties  which  requires  us  to  expand  the  definition  of  state  to 
include  information  about  die  'execution*  of  transitions. 
Primitive  transitions  do  not  execute;  they  only  fire  Instan¬ 
taneously.  We  can  represent  this  new  notion,  'execution  of 
a  transition',  in  terms  of  primitives  as  shown  in  Figures  2a 
and  2b. 

We  see  fat  Figure  2a  a  representation  of  transition  Tl 
with  its  input  and  output  places  PI  and  P2.  When  we 
interpret  this  transition  as  executing,  we  mean  that  die 
structure  of  the  transition  is  as  shown  in  Figure  2b  where 
transition  Tl  fat  expanded  into  two  ‘virtual  transitions'  and 
a  'virtual  place'  represented  by  Tl,  Tl,  P*  respectively. 
The  firing  of  T’l  indicates  the  start  of  the  execution  of  Tl; 
the  firing  of  Tl  indicates  the  end  of  the  execution  of  Tl; 
and  a  token  fat  place  P'  indicates  that  transition  Tl  fat  exe¬ 
cuting.  We  use  die  representation  given  in  Figure  2a  for 
our  computational  models.  The  parameters  associated 
with  transition  T|  are  as  follows: 

ti  «  random  variable  representing  the  time  at  which 
T,  is  enabled, 

si  «  random  variable  representing  the  time  M  which 
Ti  commences  execution, 

ft  «  random  variable  representing  the  time  at  which 
T,  finishes  execution, 

ti  'ti  ■  waiting  time  for 7i, 

ti  *  NST  •  latency  lime  for  7),  where  NST  is  net¬ 
work  start  time. 

It  is  appropriate  to  note  that  r,  and  /,  represent  the 
firing  of  the  two  virtual  transitions  associated  with  transi¬ 
tion  Ti  and  that  the  expected  value  of  ft  -  e<  is  the  input 
parameter  £/  ,  the  average  execution  lime  of  Tt ,  Latency 
is  defined  as  the  time  that  a  transition  must  wait  before  it 
is  enabled. 


EVENTS 

For  PARSIM  we  have  four  types  of  events.  They  are 
as  follows: 

Start_SimuUtion  (type  I) 

End_Simulation  (type  2) 

Trantil»on_Commences.Firing  (type?) 

Transit ion.Ends.Firing  (typed) 

The  simulator  is  ‘event-driven*;  i.e.,  the  simulation 
proceeds  by  executing  the  state  changes  as  specified  by  the 
events  in  die  Event-Table  The  Evtnt-Tnble  is  a  dynamic 
table  of  rather  simple  structure.  It  contains  a  list  of  the 
times  at  which  an  event  will  occur,  die  t>pc  and 
classification  of  event  involved,  and  an  identifier  of  the 
transition  associated  with  the  event  Events  arc  classified 
as  tidier  primary  (P)  or  conditional  (Q;  primary  events 
may  cause  the  creation  of  new  future  events  Independent 
of  the  state  of  the  system,  while  conditional  events  may 
cause  new  event  creation  based  upon  die  system  state  .  A 
typical  event  table  is  shown  fat  Table  1 

The  events  to  be  added  to  the  table  are  determined 
by  the  event-lime  prediction  routines.  These  routines 
select  events  (transition  firings)  based  upon  the  set  of 
enabled  transitions  and  die  particular  rules  of  a  given  com¬ 
pulation.  For  example,  when  several  transitions  are 
enabled,  the  next  transition  to  be  find  determines  an  event 
which  fat  to  be  placed  in  the  event  table.  That  transition  it 
selected  according  to  rules  as  docidcd  by  the  user's 
interpretation  of  the  net.  The  selection  may  be  made  at 
random  or  by  some  other  rule. 

In  PARSIM,  type  3  events  are  primary  events  since 
we  always  have  a  future  type  4  event  associated  with  die 
occurrence  of  a  type  3  event.  The  event  -  time  prediction 
routines  use  the  ‘elocution  discipline'  or  set  of  execution 
rules  which  fat  as  follows. 

Execution  Discipline 

1-  No  two  events  can  occur  at  the  same  time.  The 
minimum  time  between  the  occurrence  of  a  pair  of  events 
is  controlled  by  the  value  of  the  input  parameter 
Min_Time_Bct  ween . 

2- Transitions  can  fire  when  enabled. 

3-  A  transition  which  has  fired  cannot  be  scheduled 
for  a  subsequent  firing  until  after  its  scheduled  end  firing. 
The  virtual  transition  and  the  virtual  place  are  safe;  i.e., 
can  have  at  most  one  token. 

Simulation  Procedure 

1  Start  the  simulation,  read  input  data,  initialize. 

2  Select  evesi  from  the  event  table. 

3  Advance  clock  to  designated  time. 

4  If  primary  event  create  new  events  add  to  event 

table. 

5  Change  Status  Description. 
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6  Execute  condition*!  events  routine*. 

7  Add  new  evenu  to  event  table. 

t  Record  d*U  and  go  to  step  2. 

Set  ef  PARSIM  Proevdura 

1  Main  program  to  control  the  flow  of  the  *i muta¬ 
tion. 

2  Random  number  generator. 

3  Sue! ideal  routines  for  preparing  and  proc cuing 
output  table. 

4  Routine  for  reduction  of  the  number  of  tmui* 
tiont  firing  in  parallel.  (THU  routine  will  be  put  in 
abeyance  initially.  It  can  be  determined  within  the  context 
of  a  Petri  net.) 

3  Set  of  enabled  transitions  routine. 

6  State  change  routine.  Upon  panting  of  token* 
what  it  the  next  state. 

7  E'.nt  •  time  prediction  routine*.  These  analyte 
the  current  state  and  tire  the  state  change  routine*  to  give 
the  time  and  type  of  next  state. 

I  Routine  for  selecting  a  transition  from  the 
enabled  act  according  to  the  network  discipline. 

9  Routine  for  selecting  the  next  simuUtion  event. 

10  Routine  to  process  event  table. 

II  No  progress  routines.  These  detect  deadlock 
and  also  are  used  to  detect  Infinite  unplanned  looping. 

12  Input/Output  interface . 


J.  USER  INTERFACE 

A  preliminary  prototype  interface,  which  used 
alphanumeric  Input  only,  was  developed  for  the  description 
of  the  net  to  be  simulated.  This  interface  Includes  input* 
for  the  following. 

I.  Two  matrices  O*  and  D~  are  used  to  define  the 
topology  of  a  given  net.  The  dimensions  of  the  matrices 
arc  Nl  by  Np  representing  the  number  of  transitions  and 
places,  respectively. 

1  An  initial  state  representation  where  state  Is 
defined  as  follows. 

STATE(i)  -  (state). .. ,  suteNp)  U  BUSY, 
where  state]  represents  the  number  of  tokens  in  die  place  ] 
at  time  L 

BUSY  is  a  binary  vector  where,  for  I  in  I-  Np , 

BUSY(I)  ■  |,  if  transition  !  is  executing  at 
timet; . 

■  0,  otherwise. 

3  Transition  execution  time  is  in  a  real  array  called 
Expccted.Times  of  length  Nl 

4.  A  parameter  to  control  the  maximum  times  the 
system  can  transverse  through  a  loop. 


3.  A  parameter  to  tel  the  minimum  time  between 
the  firing  of  transitions. 

6.  An  Initial  seed  foe  the  random  number  genera¬ 
tors. 

In  addition,  the  interface  contains  an  on-line  help 
facility  which  provides  basic  Information  regarding  the 
operation  of  die  simulator.  The  preliminary  prototype 
interface  wan  developed  originally  for  a  restricted  xt  of 
users;  l.c.,  students  in  a  graduate  real-time  systems  class. 
Subsequent  work  Includes  emphasis  on  development  of  a 
graphics  based  ‘friendly*  interface  for  a  more  general  xt 
of  users.  The  graphics  based  interfxe  allows  for  provi¬ 
sion  of  input  interactively  or  via  data  files. 

PARSIM  allows  users  to  view  output  interactively  or 
to  route  output  to  any  of  the  output  devices.  Tltc  output 
includes  a  statistical  packages  which  give  statistics  on  the 
following  net  parameters. 

1.  Transition  latency  limes. 

2.  Transition  waiting  times. 

3.  Transition  execution  times  and  firing  frequencies. 

4.  Place-  token  distribution. 

3.  Total  net  execution  time. 

6.  Reachability  tree. 

The  Interface  allows,  in  addition,  a  ‘debug*  mode. 
In  this  mode,  a  user  can  print  out  tables  such  as  the  state 
table  at  each  time  sup,  the  event  or  transition  tabic  thus 
allowing  detailed  analysis  of  a  simulation  design. 

PARSIM  was  tested  on  a  number  of  small  to 
medium  sired  Petri-nets  ranging  from  somewhat  simple  to 
rather  complex  topologies.  For  xven  of  the  networks  run 
on  PARSIM,  we  present  the  resulting  data  in  Table  2. 

The  column  labeled  TOKENS  represents  the  number 
of  tokens  initially  In  the  network.  The  times  in  xcontis 
represent  the  total  real  time  for  the  simulator  to  complete 
execution.  Execution  was  completed  by  arriving  at  a  state 
in  which  tliere  were  no  possible  additional  transition  firing 
;  or  having  the  looping  limit  reached.  That  is,  the  network 
had  repeated  a  sequence  of  transition  firings  up  to  a  limit 
set  by  an  input  parameter.  This  was  Die  case  for  net 
number  6,  which  displays  the  largest  total  execution  time 
of  2.80  seconds.  Network  number  6  had  the  moss  com¬ 
plex  network  topology.  These  times  are  for  the  AT&T  PC 
6310,  with  640 K  ram,  a  20  megabyte  hard  disk,  and  a  12 
megabyte  floppy  drive.  The  times  given  do  not  include  the 
input  times  for  dexribing  Use  net  topologies.  Tlie  prelim¬ 
inary  version  of  PARSIM  consisted  of  approximately  1500 
lines  of  Ada  code  run  on  the  Meridian  AdaVanugeftm) 
Compiler  version  2.0. 
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The  current  implement* ton  of  TAKS1M  it  being 
ported  to  an  AT&T  3B2/300  Unix  Ada  environment.  The 
foe  tut  it  on  the  enhancement  of  the  user  interface  and  the 
expansion  of  the  sire  of  Petri-nets  for  which  the  tool  may 
be  applied.  A  practical  Markovian  extension  to  the  simu¬ 
lator  is  putt  of  the  enhancements  in  the  Unix  environment. 
The  Markovian  version  is  baaed  on  the  representing  the 
Petri-net  as  a  Markov  process  and  the  solution  of  rite 
resulting  equilibrium  equations.  PARSIM  win  be  used  as 
a  tool  for  the  analysis  of  real-time  concurrent  software. 
We  intend  to  use  PARSIM  bt  our  research  on  software 
reliability  in  red-time  systems  and  to  measure  the  over¬ 
head  of  rcdunancy  checks  used  in  reliable  real-time 
software  systems. 


7.  Summary 

This  paper  has  presented  an  overview  of  a  Petri-net 
tool  for  the  simulation  of  parallel  and  real-time  systems, 
The  simulator  has  been  used  to  model  complex  but  smalt 
(transitions)  nets.  PARSIM  provides  comprehensive 
statistics  on  the  execution  of  a  Petri-net.  A  variety  of 
options  are  available  for  user  input  and  output.  The 
present  version  runs  on  an  IBM  compatible  PC  with  at 
least  610  KB  memory. 


ury  at  the  University  of  Michigan.  Currently,  Dr.  Cole¬ 
man  chairs  the  Department  of  Systems  and  Computer  Sci¬ 
ence  at  Howard  University  where  he  has  been  since  1971. 
Hi*  research  and  professional  interests  center  around 
software  engineering  ,  fault-tolerant  computing,  systems 
engineering  and  technology  and  development.  He  is  a 
member  of  the  IEEE  and  the  Association  for  Computing 
Machinery. 

RONALD  ).  LEACH  received  the  B.S.,  M.A..  and 
the  PhD  in  Mathematics  from  the  University  of  Maryland 
at  College  Park  and  a  MS.  in  Computer  Science  from 
Johns  Hopkins  University.  Ik  it  a  Professor  in  the 
Department  of  Systems  and  Computer  Science  at  Howard 
University  where  he  has  been  teaching  since  1969.  His 
research  interest  include  software  engineering  and  software 
metrics,  fault-tolerant  computing,  computer  graphics  and 
analysis  of  algorithms.  Ik  it  a  member  of  the  Association 
for  Computing  Machinery,  IEEE  Computer  Society,  and 
the  Mathematical  Association  of  America. 


I.  Ackaowkdgtmtats 

The  authors  gratefully  acknowledge  support  from  the 
Department  of  Defense  under  contract  (  MDA904-M-C- 
4169.  The  second  author  also  gratefully  acknowledges 
support  from  the  Army  Research  Office  under  contract  * 
DAAL-06G-0C83.  Both  of  the  authors  are  particularly 
indebted  to  the  following  Real-Time  Systems  graduate  stu¬ 
dents  at  Howard  University  who  developed  some  of  the 
software  for  PARSIM:  Robert  Bennett.  Marcus  Reed. 
Marvin  Bingham,  and  Ivan  Brooks. 

9.  Rtfcrtnctt 

Cherry,  G.  ,  Parallel  Programming  in  ANSI  Stan¬ 
dard  Ada,  Heston  Publishing 
Company,  1984. 

Holliday,  M.  and  Vcmon,  M.  ,  ‘  A  Generalised 
Timed  Petri  Net  Model  For  Performance  Analysis  ", 
IEEE  Transactions  on  Software  Engineering,  Vol. 
SE-13,  No.  12,  December  1988.  rp  1297  -  1310. 
Peterson.  J.,  Petri  Net  Theory  and  Modeling  Of 
Systems,  Prentice-Hall ,  1981. 


DON  MICHAEL  COLEMAN  is  a  native  of  Detroit. 
Michigan.  He  received  the  B.S.,  M.S.E.  ,  and  Ph.  D. 
degrees  in  electrical  engineering  from  the  University  of 
Michigan.  From  I960  to  1961,  Dr.  Coleman  worked  as  a 
systems  engineer  at  the  A.O.  Spark  Plug  Division  of  Gen¬ 
eral  Motors,  and  from  1965  to  1971  at  tho  Institute  for 
Science  and  Technology  at.-t  Systems  Engineering  Labora- 


112  7th  Annual  National  Conference  on  Ada  Technology  1989 


Time 

Event 

Ucmificr 

CU.M 

114 

OTC  1 

0 

C 

115 

I)TC3 

6 

P 

247 

iypc4 

6 

C 

23S 

type  3 

4 

P 

TABLE  I:  A  TVriCAL  KVKNT-TABI.K 


PLACES 

TOKENS 

TKANSmONS 

B3SM 

TIMES 

2 

6 

1 

2 

0.109 

3 

S 

2 

s 

0.159 

5 

3 

4 

16 

0.9X9 

6 

12 

3 

X 

0.279 

7 

13 

3 

tl 

0.219 

IS 

X 

to 

40 

1X00 

25 

11 

IX 

66 

OiMO 

TABLE  2:  RESULTS 


© — 4—o 

pi  Ti  rj 

nCt'RII  ti  Goxitc  Trumwi 


Pi 


Ti  p  n  p< 


rtCt'RI.  £b  Timuiimi 


nr.i’Pr  u 


nctRc  ib 


7th  Annual  National  Conference  on  Ada  Technology  1989  113 


Real-Time  Pattern  Recognition  in  Ada:  On  the  Formulation  of  Keurol  Net  Recognizers 
by  Adn  Tasking  of  Massively  Parallel  Hulticomputers 

Wlllina  Arden 


Telos  Federal  Syateas 


ABSTRACT 

This  paper  examines  findings  in 
the  technologies  of  Neural  Nets,  Ada- 
Tasklng,  and  Parallel  Distributed 
Processing  (PDP)  mult 1  computers  for 
their  Integrated  approach  to  Real¬ 
time  Pattern  Recognition.  This 
approach  Involves  formulating  Neural 
Nets  in  terns  of  Ada-Tasklng  and 
examining  the  Ada-Tasklng  nodel  for 
networked  VLSI  microcomputers .  The 
result  is  then  the  class  of  pattern 
recognizers  based  upon  Neural  Nets 
which  may  be  coded  lnco  Ada  and  dis¬ 
tributed  onto  host  multicomputer 
architectures.  The  primary  benefits 
of  this  paper  arc  in  the  relation  of 
the  now  developed  technologies  of  PDP 
multlconpuccr  architectures  and 
neural  networks  to  the  Ada  applica¬ 
tion  area  of  Real-time  CJl  pattern 
recognition. 


INTRODUCTION 

Lessons  are  being  learned  in 
three  distinct  technologies  based 
upon  a  common  theme  with  powerful 
application  in  the  1EU  component  of 
CJI  systems:  Ada  Language  with  its 
Tasking  Capability,  Multicomputer 
Chip  Sets,  and  Neural  Nets.  The 
common  theme  for  all  three  tech¬ 
nologies  Is  their  enormous  potential 
with  PDP. 

This  paper  is  an  analysis  of 
lessons  learned  in  PDP  with  these 
differing  technologies  in  regard  to 
their  utility  for  Real-time  (Sub¬ 
liminal)  Pattern  Recognition.  This 
means  chat  the  process  must  complete 
below  (sub)  the  threshold  of  percep¬ 
tion  (the  linen).  This  threshold  may 
be  set  in  the  contl-second  range; 
below  this  range  events  arc  not 
detectable  by  human  observers 
unassisted  by  instrumentation,  (for 
example,  consider  what  is  meant  by 
"the  hand  is  quicker  than  the  eye"). 


As  for  Pattern  Recognition,  we 
are  speaking  of  the  identification  of 
objects  by  inputs  chat  may  be  dis¬ 
tinguished  by  pattern  (l.e.,  charac¬ 
teristics,  attributes,  structure, 
geometry,  topology,  algebra,  etc.). 
For  example,  if  crack  data  wore  to  be 
supplied  for  ICBMs  In  boost  phase 
versus  decoys  with  similar  trajec¬ 
tories,  the  sensor  crack  data  cnuld 
be  interpreted  within  cencl-seconds 
to  make  the  Identification  (In  this 
case  also  the  decision)  real  or 
decoy.  This  would  then  be  Real-time 
Pattern  Recognition. 

Neural  Nets,  which  are  fashioned 
after  brain  circuits,  are  a  powerful 
technology  of  pattern  recognition. 
Due  to  an  lnhercnc  parallel  and 
distributed  processing  nature,  these 
nets  also  offer  a  tremendous  capa¬ 
bility  for  Real-time  performance. 

This  author  has  been  researching 
a  common  logical  interface  between 
Neural  Nets  and  PDP  Multlcompucers . 
In  this  regard  Ada-Tasking  constructs 
supported  by  a  PDP  Multicomputer  Ada 
Compilation  System  (ACS)  are  Ideal 
for  flexible  Keal-dme  systems.  The 
common  logical  interface  is  demon¬ 
strated  by  representation  of  Neural 
Nets,  Ada-Tasklng,  and  the  PDP  Multi¬ 
computer  Ada  model  by  extended  Petri 
Nets . 

This  Implementation  strategy  of 
Ada  Neural  Nets  for  PDP  is  the 
material  to  follow.  Such  Ada  Neural 
Nets  assigned  to  a  PDP  Multicomputer 
offer  tremendous  potential  for  Real¬ 
time  pattern  recognition  and  are  yet 
flexible  (not  resorting  to  numerous 
costly  hardware  modifications)  and 
portable.  This  is  due  to  the  imple¬ 
mentation  strategy  of  using  Ada- 
Tssking  Software  for  Neural  Net  com¬ 
putation. 
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I  .0 


that  neural  net*  are  going  to  jje  The  power  of  the  Petri  Net  Represen- 

"norc  Important  than  the  atoa  bomb"  .  ration*  (PNRa)  Is  that  Ada-Tasklng 


The  laportance  of  Neural  Net  tech-  models  for  the  Multicomputer  may  also 

nology  to  Pattern  Recognition  should  be  represented  similarly, 

not  be  underestimated. 


RED  TOKEN 
SIGNIFYING  AN 
ACTIVATION  Of 
ot  BY  THE 
TRANSITION 
NAVI  NO  FIRED 
«  THEN 
UPDATES  A. 


FEATURE  I 


INVERTER  SYMBOL 
MAKINO  THIS 
ARC  AN 
iNarroR  arc 


RED  TOKEN 
SIGNIFYING  AN 
ACTIVATED  FEATURE 


BLUE  TOKEN  WITH 
WEIGHT  X  WHICH 
IS  WEIOHTED 
BY  LEARMNO 

KNOWLEDGE  ATOM  a 
(A  PETRI  NET  PUCE 
WITH  A  BLUE  TOKEN) 


TRANSITION  WITH  STOCHASTIC 
FIRINO  RULE  GOVERNMENT  BY 
THE  APPROPRIATE  LEARNING 
RULE: 


FEATURE  | 

FEATURES  ARE  PETRI 
NET  PLACES  WITHOUT 


2.0  ON  Ada-TASKINC  MODELS  OF  NEURAL 

NETS 

We  wilt  begin  by  exaalnlng  cho 
tlaple  PNR  of  a  Neural  Net  given  In 
Figure  2.  This  PNR  uaea  bidirec¬ 
tional  area  In  place  of  lea  equiva¬ 
lent  In  Input  and  output  area, 
placea,  and  tranaltlont.  (Thla 
exaaple  la  taken  froo  the  nore  foraal 
exaaple  given  In  Appendix  A.) 

We  will  apeak  of  placet  and 
tranaltlont  at  PNR  eleaenta  which  are 
linked  by  Input/output  area.  The 
Ada-Taaklng  aodel  of  a  PNR  Neural  Net 
la  alaply  the  correapondence  of  an 
Ada  Taak  for  each  of  the  PNR  elc- 
aenta.  The  PNR  Neural  Net  la  auch 
that  all  of  lta  eleaenta  perfora 
praceaalng  In  a  parallel  and  dlatrl- 
buted  faahlon.  In  thla  regard,  the 
taaka  which  corretpond  to  each 
eleaent  aay  alao  execute  In  a 
parallel  and  dlatrlbutcd  nanner. 

The  following  three  exaaplea  of 
Ada-Taaklng  generally  explain  the 
nature  of  the  Ada  Taaka  Involved  and 


llluatrate  how  Ada-Taaklng  aay  be 
foraulated  for  each  of  the  PNR  Neural 
Net  eleaenta: 

Exaaple  1:  Thla  taak  correaponda 
' o  place  Panther  In  Figure  2. 

taak  Panther_Recognltlon  la 

entry  TTana ltlon_one  (...)  ; 

end  Panther^Recognltlonj 

taak  body  P7nther_Recognltlon  la 

—  declaration  of  the 
activation  Indicator 
boolean  variable 

begin 

loop  accopt  Trana 1 t lon_onc 
(...)  do 

—  act  the  activation  Indl 
cator  to  one 

—  If  recognition  of  a  panther 
occura 

—  otherwtee  aet  It  to  zero, 
end  Trane Itlon^one ; 

exit  when  --  recognition  occura 
end  loop 

end  Pantherjlccognlc Ion; 

--  we  weuTd  do  taak  Top_llae>_ 
Recognition  almllarly 


FIGURE  2.  A  SIMPLE  PETRI  NET  REPRESENTATION  OF  A  NEURAL  NET 
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Exanplc  2:  This  tank  corresponds 
to  the  transition  naned  Transition^ 
one  in  Figure  2. 

task  Transit lon—onc  is 
entry  larg7  (.••); 
entry  black  (...); 
entry  cat  (•••); 
end  Translcion_onc 

task  body  Trsnsltion_onc  is 
—  declare  beolean_lndlcator 


It  should  be  aentioned  that 
Neural  Nets  (or  cognitive  systens) 
have  larger  scale  architectures  which 
nay  also  be  given  as  PNRs.  These 
larger  scale  architectures  are  called 
Schema ,  and  a  top-level  representa¬ 
tion  o(  a  Neural  Net  is  said  to  be  a 
Shenatlc  representation-  Each  of  the 
PNR  elesents  in  a  Scheaa  nay  bi 
substituted  for  by  aore  elaborate 
Neural  Nets.  This  is  illustrated  in 
Figure  3. 


begin 

loop  accept  large  (...)  do 

—  perforn  neural  net  conputa 
tlon 

—  on  inputed  value  (ire  tran 
s l tlon 

—  1£  appropriate  end  large; 

accept  black  (...)  do 
--  process  as  above 
end  black; 
accept  cat  (...)  do 

--  process  an  above 
end  cat; 

exit  when  —  desired 
recognition  occurs 
end  loop; 

end  Transit lon_one ; 

—  task  Tran*Iclon_two  is  done 

similarly  ” 

Exanplc  3:  Thla  task  corresponds 
to  place  large  in  Figure  2. 

Task  large  is 

—  appropriate  cutry  stateaents 
end  large; 

task  body  large  is 
--  if  we  refer  to  the  example 
in  Appendix  A 

--  task  large  is  for  a  place 
--  which  is  a  knowledge  ntoa 

—  and  so  we  would  declare 

—  a  variable  for  and 

--  a  boolean  variable  for  a; 

begin 

loop 


stateaents 

rule 


ure  appropriate  accept 
coopute  by  a  learning 


exit  when  --  recognition  or 


not  occurs 


end  loop; 
end  large; 

cask  black,  cat  and  hat 
could  all  be  done  slallarly 


Here  a  top-level  cognitive 
structure  called  a  Scheaa  is  given. 
Each  of  its  places  and  transitions 
can  be  filled  in  by  substituting 
other  nets.  In  chls  way,  a  top-level 
design  of  a  Neutral  Net  nay  occur. 

Similarly,  Ada  Tasks  may  cor¬ 
respond  to  Schema  PNX  elements  by 
incorporating  the  necessary  sub-net 
PNR  element  associated  tasks  into  the 
Scheaa  PNX  element  cask.  A  template 
for  the  cask  corresponding  to  the 
substituted  net  in  Figure  3  is  given 
in  the  following  example: 

task  substlcuced_net  is 

task  transt"cion__one  is 
task  place_one  Ts 
~o 
o 
o 
o 
o 
o 

end  subsc lcuced_nec 

task  body  subsclcuted_nec  is 

task  body  cransl7ion_onc  is 
cask  body  place^one  is 
o 
o 
o 
o 
o 
o 

begin 

loop 

substicuced_net; 

cran7tcion_one  ; 

place~one  ; 

o 

o 

o 

o 

o 

o 

o 

o 

o 

exit  when  --  overall 
recognition  occurs 
end  loop; 

end  substituted  net; 
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Thl*  task,  which  is  coaprlsed  of 
ail  the  casks  corresponding  to  each 
of  the  places  and  transitions  of  the 
substituted  net,  will  correspond  to 
the  transition  In  the  Scheaa  Net  of 
Figure  3. 


Since  Ada  Tasks  aay  be  Incor¬ 
porated  Into  ocher  Ada  Tasks  as  shown 
above,  the  Ada  Tasks  aay  be  slxed  to 
the  appropriate  grain  (be  It  fine  or 
coarse  grain)  of  the  Hull,  Icooputer 
architecture • 


3UISTITUTE0  NET 
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3.0  ON  Ada  COMPILATION  SYSTEMS  rOR 
PARALLEL  DISTmUTED  MULT1C0HFUTERS 

Naturally,  Ada-Tasklng  for 
Neural  Net  Recognlscr*  needs  to  be 
compiled  for  and  bound  (linked)  on  a 
computer  by  computer  basts  for  multi- 
computer  architectures. 

Lessons  learned  In  this  arena 
are  primarily  from  ALSYS  Ltd.,  In 
joint  endeavor  with  Xnmos,  to  develop 
an  ACS  for  the  Xnncs  VLSI  microcom¬ 
puter  named  the  Transputer*  The 
Transputers  have  Included: 

1)  The  Ins  T414:  32  bit 
processor,  operating  at  I0MIPS,  2K 
on-chlp  RAM,  memory  addressing  to  4 
gigabytes  and  4  links  each  providing 
20, Mbits  DMA  communications  rate. 

2)  The  Ins  T212:  16  bit 
processor  operating  at  12  HIPS,  with 
4  links. 

3)  The  TSOO:  32  bit  processor 
and  64  bit  floating  point  unit 
exceeding  I  Mflop,  4  K  bytes  on  chip 
RAM* 

These  Tranp>;ters  nay  be  linked 
point  to  point  or  via  a  "telephone 
exchange"  of  custom  silicon  for  such 
purposes  as  an  application  specific 
topology. 

The  application  specific 
topology  for  the  class  of  pattern 
recognlxcra  (Ada-Tasklng  Neural  Nets) 
J  n  this  paper  would  tend  to  be  a 
n-ary  tree  architecture.  In  most 
cases,  point  to  point  links  alone 
would  suffice. 

The  Transputer  systens 
coanerclally  available  Include: 

1)  The  Floating  Point  Systens 
T-serles  of  supercoaputers  operating 
at  128  Hflops  for  SO. an 

2)  The  Helko  Computing  Surface 
operating  at  2  Olga  Instructions  per 
second. 

Each  of  these  systens  adopt  a 
network  strategy  for  the  VLSI 
nlerocoaputers  (Transputers), 
resulting  In  parallel  distributed 
processing  suit Icomputers . 

ALSYS  Ltd.  Is  also  developing  an 
ACS  for  such  networked  Transputers. 
The  coapllatlon  sysccn  is  Co  consist 
of: 

))  Ada  Library  Managcaent 
Utilities 

2)  Ada  Coapiler 


3)  Ada  Under 

4)  Ada  Runtime  System. 

The  ACS  Is  being  (emulated  Into 
an  Ada  model  wherein  each  Ada  Task  Is 
to  be  represented  by  a  transputer 
process.  The  choice  of  which  Ada 
Task  to  schedule  at  any  tine  is  made 
by  the  Ads  Run-cine  Kernel. 

The  Ada  model  of  the  ACS  Is 
Ideal  for  Implementing  Ada  Tasks 
bated  upon  the  PNR  elements  discussed 
in  this  paper.  This  would  allow  for 
the  potential  of  massively  parallel 
distributed  processing  for  Neural  Net 
computations.  The  reason  chat  Neural 
Net  Implementation  on  a  networked 
Transputer  multicomputer  (s  Ideal  (s 
that  Ada-Tasklng  becomes  a  common 
logical  Interface  between  the  Neural 
Net  PNRs  (as  shown)  and  the  Trans¬ 
puter  network  (by  virtue  of  the  Ada 
Task  Transputer  process  model  of  the 
ACS). 

4.0  CONCLUSION 

The  preceding  has  been  an 
analysis  of  established  results.  The 
analysis  herein  clearly  Indicates  the 
potential  for  Real-  time  pattern 
recognUers  which  am  Implemented  via 
Ada-Tasklng  on  POP  mul tlcomputers . 
The  advantages  of  the  Ads  tasking 
approach  Include  the  flexibility  of 
modifications  to  the  Neural  Nets  and 
the  capability  of  porting  such 
Ada-Tasklng  Implemented  recognlser* 
to  other  hardware  platforms. 
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FIGURE  4. 
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APPENDIX  A 


Here  v«  util  give  an  example  of  a 
staple  cognitive  system  represented 
In  Fecrl  Net  fora.  This  cognitive 
system  la  represented  In  Figure  4. 


We  will  discuss  It  first  as  a 
cognitive  systea  or  C  .  Clven  our 
definition  of  a  C  as  the  quintuple: 


(R.  F.  0, 
figure  chat 
X 


C),  we  see  froa  the 


ex 
...  X 


IV 


en 

X 


IS1 


I ' 

*16* 


tXj)  -  lx,,  Xj, 
the 


*X,6> 

Froxlaal  envlron- 
aent  Is  the  proba¬ 
bility  distribution  of 
the  activation  of 
Xj...X|4  by  the 
optical  scsnne; 
the  sec  of  observables 
Is  here  (large,  black, 
cat,  hat}  given  by 
connections  X*  and 
knowledge  acoas  K, 


Before  we  go  on  and  show'fT  and  C 
we  will  first  aentlon  chat  choices  of 
and  C  will  specify  types  of  cogni¬ 
tive  systeas  and  vice  versa.  Here, 
we  will  choose  a  haraonlua  aachlne 
described  In  the  PDF  series  Voluae  1 

[471. 


For  the  haraonlua  aachlne  we 


have: 


C  such  that:  probability 


and 


(a 


1 


1) 


1  +"«W 


probability  (R,  ■  1)  •  _ [ 

:  i  a  * 


1  +  c' 


fW- 


where  Sj  ■  1  Is  a  knowledge  ntoa 
activation  and  R,  »  1  Is  a  feature 
activation  and  T  Is  a  paraneter 
called  the  Computational  Temperature 
usually  set  it  T  *  I  and  lowered  to 
force  decisions. 

Also  here: 

**  "  ^Wl*'rl  " 


and 

and 


1 


2  V 


Is. 


"  <Ka)i  _X« 

T^ajT  “here  X  1*  a 
proportionality  constant  to  be  chosen 
as  l>K>l-2/[aaXg  |K^| ) 


Here  the  subscript  <X  denotes  a 
particular  knowledge  aeon  and  X.  a 
particular  feature. 

This  C  Is  chosen  because  It 
aaxlalxes  for  haraonlua  machines, 
for  haraojj^ua  aachlne*  Is 

where  H  Is  the  harmony  between 
features  updates  and  knowledge  atom 
activations.  Ue  will  merely  state 
ll(r,  a)  as:  . 

H(r ,  a)  »/  Km  A.  h(r,  X  ) 

and  " 

h(r.  X.  )  «  r  *  X  -  X 

*  Krr 

where  X  Is  the  constant  seen 
before:  l >R> 1—2/ (max*  |x„||. 

We  ull)  not  go  Into  the  details 
of  this  foraulaclon  as  It  diverts  us 
froa  the  Intentions  of  our  example. 
The  Interested  reader  should  see  the 
chapter  on  Harmony  Theory  (n  the  PDF 
series  (47).  Let  us  slaply  state 
that  the  completion  function  given 
will  serve  to  maximise. 

Ue  have  now  specified  the  C  » 
(X,  F,  OjTTT  C) .  Let  us  reeurn*to 
the  figure  and  see  how  It  behaves  as 
a  CNN.  Firstly,  red  tokens  will 
appear  with  probability  F  on  our 
places  Xj...Rj4  with  each  pass  of 
the  optical  scanner.  These  are  the 
feature  activations.  Our 

transitions  t....c4  will  fire 
according  to  the1  completion  function 
for  knowledge  atom  updates. 
Slmllary  transitions  c,...t7  will 
fire  according  to  the9  completion 
function  for  feature  updates.  For 

several  passes  of  the  optical 

scanner  the  blue  tokens  of  the 

knowledge  acoas  will  begin  co  weight 
byA.  In  fact,  this  CHS  can  be 
trained  by  weighting  X3  for  the 
cursive  writing  giving  the  word  cat. 
This  CMN  will  then  correctly  decide 
Panther  instead  of  Top  Hat  and 

recognition  will  have  been 
performed. 

What  we  net  Ice  f  rota  this 
example  Is  that  the  PNR  readily 
models  the  C  .  Beyond  this,  the  C 
In  PNR  fora  Is  now  capable  of 
undergoing  the  powerful  techniques 
of  Petri  Net  Synthesis  and  Analysis. 
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PARALLEL  PROCESSING 
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Abstract 

Tha  Tasking  Ada  Simulation  Kit  (TASKIT)  is  a  sat 
ol  soltwara  tools  that  enables  model  builders  to 
develop  simulations  In  Ada.  The  tools  are  implemented 
as  user-callable  procedures  and  (unctions  and  provide 
simulation  services  common  to  many  types  ol  modeling 
applications.  TASKIT  uses  an  activity  oriented 
modeling  approach  that  is  a  variant  ol  discrete  event 
modeling.  An  Important  feature  of  TASKIT  Is  that  it 
enables  simulations  to  take  advantage  of  tightly 
coupled  parallel  processing.  This  parallel  processing 
capability,  which  is  completely  machine  Independent, 
has  been  successfully  tested  and  benchmarked  on  a 
parallel  processing  machine.  TASKIT  was  developed 
under  contract  to  the  Software  Technology  for 
Adaptable  Reliable  Systems  (STARS)  Program,  In 
conjunction  with  the  Naval  Research  Laboratory,  and  is 
available  through  the  STARS  Ada  Foundations 
software  repository. 


Introduction 

Discrete  event  simulations  that  require  detailed  and 
sophisticated  algorithms  often  suffer  from  slow 
execution  times.  This  is  especially  true  for  simulations 
that  have  a  large  number  of  entities.  Consequently,  the 
model  builder  often  must  sacrifice  detail  In  the  Interest 
of  faster  execution  time.  Parallel  processing  holds 
great  promise  for  these  large  and  computation¬ 
intensive  modeling  applications.  Distributing  the 
processing  for  concurrent  simulation  events  could 
greatly  reduce  the  execution  time  for  a  simulation.  This 
performance  improvement  would  allow  the  model 
builder  to  increase  the  level  of  detail  or  the  number  of 
entities  in  a  simulation  if  desired,  as  well  as  reduce  the 
turn  around  time  for'' producing  simulation  results. 

TASKIT  provides  this  parallel  processing  capability 
for  simulations.  It  takes  advantage  of  the  Ada  tasking 
mechanism  and  Is  designed  to  run  on  any  tightly 
coupled  parallel  processing  machine  that  supports 
concurrent  Ada.  Tightly  coupled  parallel  processing 
allows  processors  to  share  memory,  which  is  an 


important  requirement  for  TASKIT.  Several  machines  of 
this  type  in  the  commercial  marketplace  support 
concurrent  Ada.  Loosely  coupled  parallel  processing, 
where  processors  do  not  share  memory,  Is  not 
addressed  in  this  paper  and  is  not  supponed  by 
TASKIT. 

TASKIT  was  designed  with  two  key  goals  In  mind. 
First  and  foremost,  the  tools  had  to  be  machine 
Independent,  Including  the  parallel  processing 
capability.  The  idea  was  to  design  the  software  so  that  it 
could  be  easily  ported  to  different  machines,  and  so 
that  future  advances  in  hardware  technology  would  not 
make  the  software  obsolete.  The  second  goal  was  to 
make  the  parallel  processing  feature  optional  to  ensure 
that  the  simulation  tools  were  efficient  in  both 
sequential  and  parallel  environments.  Both  goals  were 
achieved. 

Ada  it  ■  Slmulitlon  Linquiat 

The  simulation  services  that  TASKIT  provides, 
combined  with  the  inherent  features  of  the  Ada 
programming  language,  transform  Ada  Into  a  robust 
simulation  language.  The  use  of  a  standard 
programming  language  with  appropriate  support 
routines  to  write  simulations  is  not  a  new  Idea.  This  has 
already  been  done  in  several  high  level  languages. 
However,  Ada  offers  many  advantages  over  other  high 
level  languages  for  the  development  of  simulation 
models. 

One  advantage  Is  that  the  standardization  of  Ada  is 
much  more  rigid  than  other  existing  languages.  Ada 
compilers  are  required  to  pass  a  suite  of  validation  tests 
before  they  are  fully  accredited.  The  result  of  this  rigid 
enforcement  of  standards  is  portability.  A  simulation 
written  using  TASKIT  and  Ada  can  easily  be  ported  to 
another  system  without  modification. 

Another  advantage  is  that  Ada  promotes  structure 
and  readability.  As  a  result,  simulations  constructed  in 
Ada  are  easy  to  maintain.  Maintainability  is  key  for 
many  simulations  since  models  often  have  a  long 
lifespan  and  are  frequently  changed  and  enhanced. 
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Figure  1  shows  an  example  of  a  call  to  a  TASKIT 
procedure  to  create  a  simulation  activity.  Tha  coda  In 
this  example  Is  vary  raadabla.  Tha  readability  Is  greatly 
enhanced  by  tha  Ada  feature  that  allows  tha  explicit 
naming  of  arguments  In  a  procadura  call. 


Creatajkctlvity 

tACTMTTCttSS  ■>  MBCWTJtOVt, 

STARTTIHE  »>  0.0, 
enojIke  ->  100.0, 

TIKEJTEP  ■>  10.0, 

ACTlVinjJATA  »>  AIRCRAFT_>»VE_ACTIVm_DATA)  1 


Figure  1  -  Example  of  a  call  to  a  TASKIT  procedure 

In  addition,  Ada  provides  features  that  make 
simulation  tools  written  in  Ada  easy  to  use.  For 
example,  an  Ada  procadura  can  be  overloaded  and 
can  contain  default  values  for  its  arguments.  This 
feature  enables  TASKIT  to  provide  a  great  deal  of 
power  for  the  sophisticated  user,  without  overwhelming 
tha  novice  user.  Other  Ada  features  that  promote  case 
of  use  include  packages,  information  hiding,  and  strong 
typing.  These  features  enable  the  model  builder  to  use 
an  object  oriented  approach  for  constructing 
simulations. 

Finally,  the  major  advantage  Ada  offers  is  the  task, 
which  is  a  virtual  unit  of  concurrency.  The  task  is  a  very 
powerful  feature  of  Ada  because  it  allows  for  machine 
independent  parallel  processing.  Parallel  processing 
hardware  that  can  exploit  the  use  of  the  Ada  task  exists 
today.  The  combination  of  parallel  computers  and  Ada 
tasking  holds  great  potential  (or  portable  parallel 
processing  applications  and  tools.  TASKIT  Is  one 
example  of  a  tool  that  has  tapped  this  potential. 

Tht.Actlvlty-Ori*ntiUgn 

The  fundamental  concept  behind  TASKIT  is  that 
any  system  can  be  modeled  In  terms  of  activities.  An 
activity  has  a  user-specified  start  and  end  time,  and  a 
user-written  Ada  procedure  that  contains  the  algorithms 
used  to  model  a  real  world  activity.  Each  activity  also 
has  a  unique  user-specified  time  step  associated  with  it 
so  that  the  activity  duration  can  be  subdivided  Into 
small  discrete  time  steps.  Once  an  activity  Is  started, 
TASKIT  calls  the  user's  procedure  at  each  time  step 
until  the  end  of  the  activity.  A  data  record  is  passed  to 
the  activity  procedure  at  each  time  step  to  provide  data 
local  to  the  activity.  The  structure  of  an  activity  Is  flexible 
and  allows  the  user  to  turn  the  time  step  mechanism  on 
and  off.  When  the  time  step  is  turned  off,  an  activity  will 
only  be  called  once  at  the  start  and  once  at  the  end. 


This  activity  orientation  Is  a  variant  of  discrete  event 
modeling.  Essentially,  an  activity  is  a  construct  that 
combines  a  series  of  regularly  occurring  discrete 
events  to  represent  a  continuous  process.  In  discrete 
event  simulation,  an  activity  can  be  represented  by  an 
event  that  reschedules  itself  at  a  fixed  time  Increment. 
Conversely,  an  activity  can  be  used  to  represent  a 
discrete  event  by  setting  the  start  time  equal  to  the  end 
time  and  setting  the  time  step  to  zero. 

The  primary  reason  for  adopting  the  activity 
orientation  In  TASKIT  was  to  set  up  a  simulation 
methodology  conducive  to  parallel  processing. 
Instantaneous  discrete  events  do  not  conjure  up  a 
notion  of  concurrency.  Activities  however,  can 
conceptually  be  thought  of  as  executing  in  parallel  with 
other  activities,  since  an  activity  has  a  duration  and  is 
not  Instantaneous.  TASKIT  takes  the  conceptual  notion 
of  parallel  activities  and  turns  it  into  a  reality  through  the 
use  of  the  Ada  tasking  mechanism. 

For  each  activity  created  by  the  user,  an  Ada  task  is 
created  by  TASKIT.  The  call  to  the  user’s  activity 
procedure  Is  embedded  within  the  task  that  Is  created. 
It  is  Important  to  note  that  the  user  does  not  create  Ada 
tasks,  only  procedures.  It  Is  TASKITs  Job  to  map  the 
activity  procedures  to  an  Ada  tasking  environment. 
Since  TASKJT  creates  and  manages  the  Ada  tasks,  the 
tasking  feature  is  optional.  If  parallel  hardware  is 
unavailable,  the  user  can  turn  off  the  tasking  feature  to 
avoid  the  additional  overhead  associated  with  tasks. 

AclMUti  ind  Parallel  Proctnlng 

There  are  some  rules  as  to  when  activities  can  take 
advantage  of  parallel  processing.  The  first  rule  is  that 
TASKIT  can  only  execute  activities  In  parallel  if  their 
corresponding  time  steps  occur  at  the  same  point  in 
simulated  time.  This  is  not  an  unreasonable 
assumption.  The  alternative  is  to  allow  a  situation 
where  one  activity  could  be  farther  ahead  in  simulated 
time  than  another  activity,  although  both  are  executing 
concurrently.  Letting  activities  get  ahead  of  one 
another  can  lead  to  problems,  especially  if  a  slower 
activity  causes  some  change  in  the  system  that  affects  a 
faster  activity  somewhere  ahead  in  the  future.  That  is 
not  to  say  it  is  impossible  to  handle  this  type  of 
situation.  Rather,  it  is  much  less  complex  and  more 
intuitive  to  only  allow  activities  that  occur  at  the  same 
time  to  execute  concurrently.  TASKIT  provides  a 
method  for  synchronizing  activities  to  maximize  the 
amount  of  parallelism. 

The  second  rule  for  parallel  activities  involves  the 
concept  of  an  activity  class.  A  class  consists  of  one  or 
more  identical  activities  that  may  or  may  not  operate  on 
the  same  data.  In  TASKIT,  activities  that  belong  to  the 
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same  class  can  execute  concurrently.  The  model 
builder  specifies  whether  or  not  the  activities  in  a  given 
class  are  to  execute  in  parallel.  In  addition  to  having  the 
capability  (or  activities  within  a  class  to  execute  in 
parallel,  it  is  also  possible  for  different  classes  to 
execute  concurrently.  For  two  or  more  classes  to 
execute  In  parallel,  they  must  have  the  same 
user-specified  priority.  The  reason  for  the  priority  is  to 
handle  the  case  where  one  class  of  activities  may 
depend  upon  the  results  of  another  activity  class,  even 
though  they  occur  at  the  same  time.  Figure  2  illustrates 
the  concept  of  activities  within  a  class,  as  well  as 
multiple  classes  executing  concurrently. 


Figure  2  -  Activities  of  the  same  class  execute 
concurrently  and  activity  classes  of  the  same  priority 
execute  concurrently 


The  third  rule  for  parallel  activities  pertains  to  the 
use  of  global  data.  On  a  tightly  coupled  parallel 
computer,  shared  memory  allows  parallel  activities  to 
access  shared  global  data.  The  user  must  take  certain 
precautions  when  using  global  data  in  a  parallel 
environment.  Read  operations  on  global  data  require 
no  special  treatment  for  parallel  activities.  However, 
read-write  operations  performed  on  the  same  global 
object  by  parallel  activities  can  cause  problems. 
TASKIT  provides  a  semaphore  package  so  that  the 
model  builder  can  restrict  the  access  to  certain  areas  of 
global  data.  A  semaphore  simply  queues  up  requests 
to  a  critical  code  section  where  access  to  a  restricted 
resource  occurs.  The  resource  can  be  an  area  of  global 
data,  a  file,  or  an  external  device.  Semaphores  are 
necessary  In  some  cases,  but  their  use  should  be 
minimized.  A  resource  protected  by  a  semaphore 
causes  parallel  activities  requiring  that  resource  to 
remain  In  a  wait  state  until  access  is  obtained.  This 
results  In  a  loss  of  parallelism. 

Following  the  rules  described  above  will  not 
guarantee  that  a  simulation  with  parallel  activities  will 
run  faster  on  a  parallel  computer  than  on  a  sequential 
computer.  Parallel  processing  is  more  like  an 
investment  than  a  gift.  An  investment  must  be  made 
before  profit  is  realized.  In  the  TASKIT  simulation 
environment,  the  investment  Is  the  processing 
overhead  required  to  manage  the  Ada  tasks  at  the 
TASKIT  tool  level  and  at  the  Ada  run  time  level  for  a 
particular  machine.  The  profit  is  an  overall  reduction  in 
computation  time.  In  order  to  realize  a  profit,  the  time 
saved  by  distributing  computation  must  be  greater  than 
the  time  spent  managing  tasks. 

To  realize  a  computational  profit,  a  TASKIT 
simulation  must  have  parallel  activities  that  contain 
sufficient  granularity.  Granularity  denotes  the  duration 
of  processing  between  synchronization  points  in  a  task, 
it  Is  a  measure  of  the  amount  of  work  to  be  performed 
by  a  particular  activity.  For  example,  an  activity  that 
represents  a  radar  site  trying  to  detect  an  incoming 
missile  would  have  a  low  granularity  if  the  activity  only 
performed  a  simple  range  check  for  radar  detection.  If 
the  activity  used  a  sophisticated  radar  detection 
algorithm,  it  would  have  a  much  higher  granularity.  A 
set  of  parallel  activities  with  very  little  computation  does 
not  have  sufficient  granularity  to  justify  an  investment  In 
parallel  processing,  while  a  computation-intensive  set 
of  parallel  activities  should  realize  a  handsome  profit. 

In  addition  to  having  parallel  activities  oi  sufficient 
granularity,  the  application  should  also  have  a  suitable 
number  of  parallel  activities.  The  model  builder  has 
control  over  the  number  of  activities  within  a  class  and 
the  number  of  activity  classes.  The  number  of  parallel 
activities  should  map  closely  to  the  number  of 
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processors.  Fewer  concurrent  activities  than  processors 
results  in  unused  processors,  while  more  concurrent 
activities  than  processors  results  in  extra  context 
switching. 

Benchmark  Results  For  TASK  FT  on  a  Parallel 

Machine 

Benchmark  experiments  were  constructed  to 
validate  TASKIT  in  a  parallel  processing  environment. 
Two  goats  were  set  when  designing  the  experiments 
for  the  benchmark.  The  first  goal  was  to  demonstrate 
that  TASKIT  can  be  ported  to  a  parallel  processing 
machine  without  requiring  modification.  The  second 
goal  was  to  show  that  simulations  using  TASKIT  on  a 
parallel  machine  can  experience  performance 
improvements  under  the  appropriate  conditions.  Both 
goals  were  achieved. 

A  test  simulation  was  constructed  using  the  TASKIT 
tools  and  then  ported  to  an  Encore  Multimax™.  The 
Encore  is  a  tightly  coupled  parallel  processing  machine 
that  supports  a  validated  concurrent  Ada  compiler.  The 
Encore  used  for  the  benchmark  contained  12 
processors  although  the  machine  was  capable  of 
utilizing  up  to  20  processors. 

The  first  goal  of  demonstrating  portability  was  met 
by  successfully  compiling  the  test  simulation  and  the 
TASKIT  software  on  the  Encore.  No  modification  was 
required  for  TASKIT  to  take  advantage  of  the  parallel 
processing  capability  of  the  Encore.  This  was  a 
significant  achievement  since  TASKIT  was  developed 
on  a  sequential  machine,  a  VAX™  1 1/780.  The  TASKIT 
development  team  did  not  have  access  to  any  parallel 
processing  hardware  when  TASKIT  was  being 
constructed.  TASKIT  was  developed  using  a  'software 
first*  approach.  This  approach  emphasizes  machine 
independence  and  more  Importantly,  reverses  the 
natural  tendency  to  develop  software  specifically  for 
existing  or  available  hardware. 

After  successfully  rehosting  TASKIT  to  the  Encore, 
the  second  goal  of  the  benchmark  was  to  prove  that 
TASKIT  simulations  could  benefit  from  parallel 
processing  under  appropriate  conditions.  As  discussed 
earlier,  only  activities  of  the  same  priority  that  occur  at 
the  same  point  in  simulated  time  can  be  executed 
concurrently.  For  this  benchmark,  all  activities  in  the  test 
simulation  belong  to  a  single  class  and  therefore  have 
the  same  priority.  Additionally,  all  activities  are 
synchronized  to  the  same  time  step.  This  represents  an 
ideal  case.  (An  actual  simulation  might  require  the 
activity  classes  to  have  different  priorities  or  time  steps.) 

Mukimax  Is  a  trademark  o)  th«  Encora  Computer  Corporation 
VAX  Is  a  Iradamaik  o ( tha  Dijiul  Equipment  Corporation 


The  work  performed  by  the  activities  In  the  benchmark 
consists  of  a  floating  point  addition  that  operates  on 
local  activity  data.  This  addition  operation  was  placed 
Inside  a  loop  so  that  various  levels  of  granularity  could 
be  measured. 

The  benchmark  consisted  of  three  main  cases  for 
the  test  simulation.  The  first  case  contained  oniy  one 
activity,  the  second  case  five  activities,  and  the  third 
case  ten  activities.  For  each  case,  the  test  simulation 
was  executed  for  1000  simulation  seconds  with  a  time 
step  of  10  seconds.  The  granularity  was  parametrized 
with  values  of  0,  100,  1000,  and  5000  representing  the 
number  of  additions  performed  by  each  activity. 

Figures  3,  4,  and  5  show  the  results  of  executing 
the  three  cases  in  both  a  sequential  mode  using  one 
processor  and  In  a  parallel  mode  using  10  processors. 
In  the  parallel  mode,  a  total  of  12  processors  was 
available.  However,  the  main  task  and  another  support 
task  used  two  processors  so  that  to  processors  were 
available  for  simulation  activities.  The  execution  time 
shown  In  the  figures  represents  the  cumulative  time  for 
replicating  the  test  simulation  10  times  for  each  case. 

Figure  3  shows  the  obvious  case  of  one  activity 
obtaining  no  benefit  from  parallel  processing.  This 
case  illustrates  the  expected  result  that  the  parallel 
mode  is  less  efficient  when  one  activity  is  involved. 
Figure  4  shows  that  in  the  five  activity  case,  parallel 
processing  begins  to  show  a  computational  profit.  The 
profit  is  small  at  first,  however  the  profit  margin 
increases  as  the  granularity  increases.  Figure  5  further 
illustrates  this  point.  This  case  has  a  better  mapping  of 
activities  to  processors.  As  a  result,  the  profit  from 
parallel  processing  is  greater  than  In  the  five  activity 
case. 


One  Activity 


Granularity' 


Figure  3  -  Encore  benchmark  results  for  one  activity 
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Figure  4  -  Encore  benchmark  results  for  five  activities 
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Figure  5  -  Encore  benchmark  results  for  t6n  activities 

Speedup  Is  usually  the  bottom  line  when  H  comes 
to  parallel  processing  benchmarks.  In  the  cases 
performed,  the  maximum  speedup  achieved  was  5.3  for 
ten  processors  and  ten  activities.  However,  had  more 
cases  been  executed  at  higher  granularities,  the 
speedup  would  have  approached  10.0,  and  a  linear 
speedup  could  have  been  achieved.  The  point  Is  that 
TASKIT  Is  a  set  of  tools,  not  an  application,  and 
speedup  is  an  application  dependent  measurement. 

It  Is  difficult  to  extrapolate  the  results  of  the 
benchmark  to  make'  conclusions  about  the  speedup 
that  a  particular  simulation  application  might  achieve  by 
using  TASKIT.  Thor,  is  no  guarantee  that  a  simulation 
using  TASKIT  will  benefit  from  parallel  processing. 
Some  simulations  may  benefit  while  others  may  not. 
The  test  simulation  represents  an  ideal  case  for  an 
application  that  uses  TASKIT.  The  results  of  the 
benchmark  show  that  this  ideal  case  performed  as 
expected.  It  emphasizes  the  Important  role  that 


granularity  plays  in  determining  the  benefit  of  parallel 
processing.  Even  the  Ideal  case  does  not  benefit  from 
parallel  processing  it  the  amount  of  computation 
performed  by  the  activities  is  not  sufficient. 

ThA.BtaLfll.BQth  World* 

As  far  as  the  model  builder  is  concerned.  TASKIT 
represents  a  tow  risk,  yet  a  potentially  high  gain 
proposition.  TASKIT  is  most  beneficial  for  simulations 
that  are  well  suited  for  parallel  processing.  Even  if 
parallel  hardware  is  not  available,  a  simulation  that  Is 
prepared  for  parallel  processing  can  be  developed  and 
used  in  a  sequential  environment.  When  the 
appropriate  parallel  hardware  becomes  available,  the 
simulation  can  be  rehosted  to  h  without  modification. 

For  the  case  where  a  simulation  is  not  inherently 
parallel,  TASKIT  is  still  a  valuable  tool.  Since  TASKIT 
is  designed  to  execute  efficiently  in  a  sequential  Ada 
environment,  it  can  be  used  tike  any  ordinary 
sequential  simulation  language.  No  additional 
language  training  is  required  for  an  Ada  programmer  to 
build  simulations  using  TASKIT.  The  Ada  programmer 
needs  only  to  learn  the  TASKIT  packages,  not  a 
specialized  simulation  language.  The  number  of  Ada 
programmers  is  growing  as  Is  the  general  level  of 
experience  with  Ada.  Additionally,  the  number  of  good 
Ada  compilers  is  steadily  increasing  and  Ada  compilers 
are  starling  to  emerge  on  personal  computers.  As  a 
result,  software  and  hardware  support  for  TASKIT 
simulations  is  widely  available. 

The  key  to  TASK  IT's  versatility  Is  machine  and 
environment  independence.  Virtually  any  computer  that 
has  an  Ada  compiler  can  be  used  for  TASKIT 
simulations.  TASKIT  has  been  successfully  tested  for 
portability  on  a  VAX  using  the  VMS'*  operating  system, 
a  Harris  computer  running  under  UNIX*,  and  the  UNIX 
based  Encore  multi-processor  used  for  the  benchmark. 
TASKIT  was  successfully  tested  in  these  diverse 
environments  without  requiring  any  modification. 

More  Importantly,  TASKIT  leaves  the  door  open  for 
future  hardware  advances.  It  is  conceivable  that 
someday  multi-processors  that  support  concurrent  Ada 
could  be  available  as  desk  top  personal  computers. 
With  virtually  no  risk,  simulation  developers  can  begin 
preparing  now  for  this  future  hardware  by  writing 
simulations  In  TASKIT  and  Ada  today.  Given  the  rate  at 
which  hardware  technology  is  advancing  and  the 
typical  lifespan  of  a  simulation,  it  Is  a  sound  decision  to 
design  simulation  software  not  only  for  the  present,  but 
also  for  the  future. 

VMS  I*  i  fcadem*k  ot  th«  Digital  Equipment  Corporation 
UNIX  la  a  (*g  star  ad  trademark  o(  AT&T 
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Qlhtr  Stfvteti.Prpvkhd  by  TASKIX 
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TASKIT  if  a  robust  simulation  tool  kit  and  provides 
othar  Important  simulation  sarvicas  in  addition  to 
activity  managamant.  Thasa  sarvicas  Include:  statistics 
oollaction  and  reporting  tools,  a  plotting  package  tor 
displaying  simulation  statistics,  a  performance  analyzer 
that  collects  data  on  the  execution  time  ol  the 
simulation,  resource  protection  tools  to  protect  global 
data  in  a  parallel  environment,  a  random  number  and 
probability  distribution  package,  keyed  linked  list 
services,  and  a  simulation  data  management  system 
that  enables  the  analyst  to  input  and  manage 
simulation  data  in  a  spreadsheet  format.  The  services 
that  are  provided  are  organized  Into  Ada  packages  so 
that  the  model  builder  can  selectively  use  only  the 
services  required. 

Inlarmallpn  on  Obtaining  TASKIT 

TASKIT  Is  part  of  the  STARS  Ada  Foundations 
software  repository  and  can  be  obtained  from  the  Naval 
Research  Laboratory.  For  more  information  contact: 

Naval  Research  Laboratory 
Code  5150,  Bldg  1,  Room  321 
4555  Overlook  Avenue,  Southwest 
Washington,  D.C.  20375-5000 
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Ada  Run-Time  Environment  Considerations  For  Simulation 
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Abstract 

the  choice  of  Ada  as  the  Implementation 
language  for  simulation  system*  raises  some 
run-time  environment  concern*.  In  evaluating 
«n  Alia  language  system  for  simulation,  these 
run-time  environment  issues  must  he 
considered.  These  Issues  Include  the  support  for 
migration  from  FORTRAN  to  Ada  and  the 
support  for  exploiting  target  system  features. 


Introduction 

Over  the  years,  some  computer  vendors 
have  Improved  and  tailored  their  machine 
architecture  and  the  operating  systems  for 
simulation  applications.  We  have  seen  systems 
evolve  from  a  uni-processor  configuration  to 
multi-processor  distributed  system 
configurations.  The  concept  of  shared  memor y 
architecture  was  also  introduced.  Along  with 
the  evolution  of  the  hardware  configurations, 
the  system  software  (specifically  the  operating 
systems  and  compilers)  underwent  changes  to 
tailor  machine-level  access  to  the  application 
requirements. 

Traditionally,  FORTRAN  was  used  as  the 
language  for  implementation  of  simulation 
software.  Compiler  vendors  were  free  to 
enhance  the  language  Implementation  to  best 
suit  their  language  offering  to  their 
architecture.  Library  routines  were  provided  to 
exercise  and  control  various  system  resources. 

With  the  adoption  of  Ada  as  tiie  language 
of  implementation  for  most  of  the  simulation 
software,  some  of  the  issues  have  to  be 
approached  in  a  slightly  different  fashion. 


Compiler  vendors  do  not  have  the  freedom  to 
enhance  the  language.  They  can  only  provide 
add-on  features;  however,  these  features  arc  not 
supposed  to  change  the  semantics  of  the 
program  as  defined  by  the  Ada  language 
standard.  The  implementors  of  the  simulation 
software  arc  faced  with  using  a  new  language 
system  that  seems  to  require  new  approach  In 
tiie  design.  Therefore,  implementors  of  both 
the  simulation  and  the  system  software  need  to 
take  a  different  approach  to  solve  their 
problems. 

Real-time  application  software  (like  a 
simulation  system)  has  stringent  liming 
constraints.  It  also  has  some  special  run-time 
requirements,  in  general.  This  paper  addresses 
the  following  run-time  environment  issues  from 
the  point  of  view  of  implementing  a  real-time 
system  in  Ada: 

•  Migration  from  FORTRAN  to  Ada; 

•  OS  tasking  as  opposed  to  Ada  tasking; 

•  Access  to  operating  system  features; 

•  Shared  memory  configurations; 

•  Multi-processing  system  features;  and 

•  Symbolic  real-time  debugging  tools. 

Migration  from  FORTRAN  to  Ada 

In  the  past,  the  simulation  software  was 
mostly  written  in  FORTRAN.  It  is  possible  that 
some  parts  of  this  software  can  be  reused  in 
new  projects  where  Ada  is  being  used  as  the 
implementation  language.  These  parts  can  be 
rewritten  in  Ada  in  an  incremental  fashion, 
which  provides  a  gradual  migration  path  for  the 
implementor.  However,  for  this  approach  to 
work,  tiie  Ada  language  system  should  satisfy 
the  following  requirements  which  become 
significant  if  a  large  amount  of  FORTRAN  code 
is  reused.  (The  idea  here  is  to  use  the 
FORTRAN  code  without  modification.) 
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(1)  The  Ad»  Compiler  must  support  pragu* 
INTERFACE  to  FORTRAN. 

This  pragma  allow*  subprograms  written  In 
FORTRAN  to  be  called  from  Ada 
procedures.  The  Ada  language  docs  not 
mandate  Ada  compilers  to  support  this 
pragma;  however,  many  Ada  compilers  do. 

(2)  The  Interface  between  Ada  and  FORTRAN 
should  be  as  n»t»r»t  as  possible. 

The  source  eodc  for  the  call  from  Ada  to 
FORTRAN  should  look  as  If  the  called 
procedure  Is  written  In  Ada.  No  special 
requirements  is  to  be  put  on  the  programmer 
In  passing  arguments  to  the  called 
subprogram.  For  example,  the  Ada 
programmer  should  not  be  required  to  pass 
the  address  of  the  actual  argument  rather 
than  the  argument  Itself.  This  Is  mainly 
because  the  programmer  should  have  to  do 
minimum  source  modification  when  the 
FORTRAN  subprogram  la  reimplemented  In 
Ada.  (The  only  source  mollification  the 
programmer  has  to  do  Is  to  remove  the 
pragma  INTERFACE  for  the  subprogram 
and  supply  the  body  coiled  In  Ada.) 

Further,  alt  relevant  Ada  data  types  must 
be  mapped  to  the  FORTRAN  data  types  In 
a  convenient  fashion. 

(3)  A  mechanism  to  map  Ada  package 
specifications  to  FORTRAN  COMMON 
blocks  should  be  provided. 

This  is  necessary  for  the  simulation  program 
that  is  made  up  of  Ada  and  FORTRAN 
code  to  work  on  a  single  set  or  global  data 
objects.  In  Ada,  global  objects  arc  declared 
in  package  specifications  and  in  FORTRAN, 
they  are  placed  In  COMMON  blocks. 

OS  tasking  as  opposed  to  Ada  tasking 

The  Ada  language  has  constructs  (known  as 
casks)  to  support  parallel  programming.  These 
constructs  are  unsuitable  in  some  applications 
where  the  task's  priority  has  to  be  adjusted 
dynamically  or  the  task  Is  to  be 
blocked /aborted  if  Us  time-frame  has  lapsed  or 
a  failure  in  the  task  needs  to  be  notified  to  a 
monitor.  Also,  Ada  tasking  does  not  efficiently 
support  periodic  scheduling.  Further,  most  of 
the  Implementations  of  Ada  tasking  are  not 
efficient.  There  is  a  significant  amount  of 
overhead  in  a  task  switch.  In  a  real-time 
environment,  meeting  the  individual  timing 
requirements  of  each  task  is  important. 


Further,  a  predictable  behavior  of  the  run-time 
system  Is  crucial*.  Where  these  characteristics 
are  less  Important,  It  is  possible  to  adopt  Ada 
tasking  constructs.  However,  for  more  critical 
portions  of  the  simulation  software,  It  may  be 
necessary  to  look  for  some  other  kind  of 
support. 

The  operating  system  allows  the  user  to 
define  his  own  tasks  (also  known  as  processes). 
These  processes  can  be  individually  controlled 
and  monitored  by  another  process  called  a 
monitor.  The  monitor  can  activate  other 
subprocesscs,  adjust  the  system  load, 
dynamically  change  the  priority  of  processes, 
and  so  on.  This  gives  the  user  some  flexibility 
In  the  design  of  his  simulation  system.  Major 
parts  of  the  simulation  system  (e.  g.,  Avionics, 
Visual,  Kngincs.  etc.)  can  thus  be  designed  and 
Implemented  as  separate  processes  with  the 
main  scheduler  (or  the  operating  system  Itself) 
controlling  their  execution,  barge  simulation 
programs  may  adopt  this  approach  rather  than 
using  the  Ada  tasking  model. 

However,  for  the  latter  approach  to  work, 
the  Ada  system  should  allow  the  separate 
processes  to  share  a  common  data.  This  data  is 
normally  declared  in  Ada  package 
specifications.  Front  the  programmer's  point  of 
view,  accessing  objects  in  these  package 
specifications  should  not  require  the  knowledge 
of  the  tasking  model.  This  also  requires  that 
there  should  be  one  and  only  one  common  data 
set  loaded  into  the  memory  for  the  simulation 
system.  Most  importantly,  there  should  be  no 
run-time  penalty  for  structuring  the  simulation 
system  in  this  fashion.  Further,  the  Ada 
language  system  should  have  facilities  to  enable 
a  process  written  in  Ada  to  control  another 
process.  The  user  should  not  have  to  write 
Assembly  or  FORTRAN  code  to  achieve  the 
desired  functionality.  These,  are  examined  in 
greater  detail  In  the  following  sections. 

Under  the  OS  process  model,  one  may  require 
facilities  for  resource  locking  when  there  arc 
more  than  one  process  in  the  application 
program.  It  may  be  necessary  that  when  one 
process  is  manipulating  a  set  of  data,  all  other 
processes  be  denied  access  to  It.  It  would  be 
desirable  to  have  resource  locking  facilities 
available  at  the  Ada  programming  level. 
Therefore,  the  language  system  should  provide 
procedures  and  functions  to  achieve  data 
locking,  for  example,  through  Test-and-Set 
primitive  operations. 
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Access  to  Operating  System  features 

Most  ^crating  systems  provide  support  for 
following  facilities: 

•  process  manipulation  and  (antral  —  This 
facilitates  dynamic  creation  of  processes, 
actlvating/hlocking/aherllng  processes, 
dynamic  adjustments  of  priorities,  settling 
state  change  of  processes,  and  so  on 

•  praem  communication  —  This  allows 
interprocess  communication  for  sending  and 
receiving  messages,  data,  notification  of 
status,  and  so  on 

•  timer  management  —  This  allows  selling  of 
periodic  timer  Interrupts  for  regular  system 
monitoring  and  load  adjustments,  and  time* 
slice  management 

•  high  speed  input/output  —  allowing  for  rapid 
data  collection  and  transfer. 

Efficient  Implementations  of  these  functions  Is 
required  for  a  simulation  application  program 
to  function  well. 

These  OS  functions  should  be  made  available  to 
the  Ada  programmer  as  procedure/function 
calls.  Errors  generated  by  these  support 
routines  must  be  mapped  to  exceptions  so  that 
the  program  can  react  to  these  errors  In  a 
consistent  fashion.  These  OS  functions  should 
be  In  the  standard  library  that  is  supplied  by 
the  compiler  implementor.  The  implementor 
should  supply  package  specifications  defining 
the  Interface  to  these  functions.  The  simulation 
programmer  should  not  have  to  write  these 
packages. 

The  Ada  Real-Time  Environment  Working 
Group  (ARTEWG)  (under  the  guidance  of  the 
Ada  Joint  Program  Office}  is  working  on 
standardizing  the  run-time  interface  to  seme  of 
the  required  OS  features.  When  this  standard  is 
established  and  adopted  by  the  compiler 
vendors,  the  Ada  programmer  will  be  able  to 
make  use  of  these  features.  However,  he  will 
have  to  cvalunte  the  supplied  features  from  the 
point  of  cflicieney  of  its  implementation. 

Shared  memory  configurations 

For  a  very  large  simulation,  the  software 
may  require  more  than  one  processor  for 
execution.  One  set  of  processes  of  the 
simulation  software  may  run  on  one  processor, 
second  set  on  a  second  processor,  and  so  on. 
However,  there  is  a  certain  amount  of  data  that 


must  be  shared  by  some  or  all  of  these 
processes.  Some  hardware  vendors  hove  come 
up  with  loosely  coupled  systems  configured  in 
such  a  fashion  that  the  various  processors  In 
the  system  tharc  memory.  That  Is,  a  certain 
part  of  the  system  memory  Is  common  to  all  of 
the  processors  In  the  configurations.  The  data 
of  the  simulation  software  that  is  common  to 
the  different  processors  Is  placed  In  this  shared 
memory.  In  such  a  configuration,  the  only  way 
of  communication  between  processes  running  on 
the  different  processors  may  be  through  the 
shared  memory. 

Although  there  Is  a  hardware  solution  to 
the  problem,  the  software  solution  needs  to  be 
evaluated.  The  data  common  to  more  than  one 
process  running  on  different  processors  In  this 
configuration  needs  to  be  placed  in  the  shared 
memory.  The  simulation  software  designer 
needs  to  know  this  configuration  merely  for 
organizing  his  data  structures,  ft  should  not 
have  a  major  design  impact  for  the  designer. 
The  programmer  of  such  software  should  not 
have  to  know  where  the  common  data  (which, 
again,  Is  in  an  Ada  package  specification)  Is 
located  at  run-time.  Further,  there  should  not 
be  any  performance  penalty  for  choosing  the 
shared  memory  configuration.  The  compiler 
vendor  should  supply  the  tools  required  to  build 
data  images  for  thtsc  shared  data,  to  build 
executable  processes  using  the  shared  data,  and 
to  load  the  shared  memory  with  the  appropriate 
data. 

Multi-processing  system  features 

There  Is  another  hardware  solution  for  some 
of  the  large  simulation  systems:  a  closely 
coupled  multi-processing  system.  All  of  the 
processors  In  such  a  system  share  all  of  the 
available  memory,  and  typically,  one  of  the 
processors  in  the  system  performs  the 
supervisory  functions.  In  such  systems, 
processes  can  communicate  with  processes 
running  on  the  same  system  by  sending 
messages  or  through  shared  data. 

In  a  multi-processing  system,  the  process 
scheduling  may  be  done  in  one  of  three  different 
ways:  through  programmer  control,  manual 
Intervention,  or  operating  system  control.  Most 
simulation  programs  prefer  the  first  approach 
over  the  other  two.  This  gives  the  simulation 
designer  a  closer  control  of  the  processes  in  the 
system.  The  functions  that  are  necessary  are: 
scheduling  processes  for  execution  on  a 
processor  in  the  multi-processor  system, 
removing  a  process  that  is  executing  on  a 
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processor  when  Its  time  frame  (or  lime  slice) 
has  expired,  or  moving  a  process  from  one 
processor  queue  to  another.  Once  again,  the 
compiler  vendor  should  supply  the  multi¬ 
processing  support  functions  and  the  associated 
package  specification  In  the  standard  software 
package  If  the  simulation  software  requires 
programmer  (dynamic)  control  for  process 
scheduling.  In  addition,  the  requirements  listed 
In  the  section  on  shared  memory  configurations 
arc  also  applicable. 

Symbolic  real-time  debugging  tools 

The  Ada  Programming  Support 
Environment  (APSE)  should  provide  tools  for 
real-time  debugging.  These  tools  should  not 
require  the  user  to  refer  to  machine  locations  In 
the  program,  but  should  use  symbolic  names 
from  those  programs.  A  symbolic  real-time 
debugger  Is  required.  However,  conventional 
debuggers  arc  known  to  alter  the  real-time 
behavior  of  simulation  progrants. 

When  n  program  has  reached  the  semi- 
production  level,  the  user  can  use  a  symbolic 
real-time  monitor3.  Such  a  tool  will  allow  the 
user  to  monitor  certain  data  objects  in  real¬ 
time  without  impacting  the  performance  or  the 
real-time  nature  or  the  program.  This  Is  due  to 
the  fact  that  the  tool  does  not  Interrupt  the 
execution  of  the  program  to  provide  Information 
about  the  program  bclug  debugged.  When  the 
real-time  monitor  shows  a  potential  Incorrect 
execution  in  the  program,  the  user  should  be 
able  to  activate  a  debugger  and  start  debugging 
in  the  conventional  fashion.  These  debugging 
tools  should  operate  with  the  source  level 
reference  from  the  user. 

The  symbolic  debugging  tools  should  also 
have  the  ability  to  Introduce  faults  lulu  the 
program  for  testing  or  training  purposes  and 
enable  checking  of  all  possible  logic  paths  In  the 
program.  Further,  these  debugging  tools  should 
be  able  to  support  the  application  program 
running  In  a  multi-processing  shared  memory 
configuration. 


Conclusion 

Various  run-time  environment  factors  need 
to  be  looked  at  when  evaluating  an  Ada 
Programming  Support  Environment  for 
simulation.  These  factors  are  not  just  limited  to 
the  run-time  speed  of  the  code  generated  by  the 
compiler  or  the  efficiency  of  the  core  run-time 
system  facilities.  One  needs  to  evaluate  the 
language  support  for  mixed  language 
programming,  support  for  shared  memory 


configurations,  integration  with  the  underlying 
operating  system  support,  and  rcal-tlt  e 
debugging  facilities. 
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aust-raot 

In  designing  the  multi-tasking  signal  pmctiiing  software.  u  i*  important 
10  too*  tt*c  dynamic  behavior  and  timing  pctfetmsnce  of  Ok  process 
model  In  a  real-time  environment  However.  One  <«  Ok  Hardware  and 
software  result  tiect  of  an  embedded  apron.  Ok  designer  may  not  have  all 
the  Infaimaiton  necessary  to  fully  undermnd  the  model  or  the 
convenience  to  optimise  the  model'*  performance  THU  paper  describes 
reitrfcrlon*  encountered  and  reiult*  obtained  In  benchmarking  Ok  real, 
time  proeerue*.  originally  wOiten  in  native  xaxmhly  language,  against  the 
aame  processes  coded  In  Ada  Both  etecutahle  cede*  were  downloaded 
Inin  a  Motorola  61010  embedded  microprocc**or  to  obtain  the 
benchmark*.  Simulation  of  0k  *amc  processes  In  Ada  and  eoeouing  them 
on  a  self-tirgcleJ  VAXK600  demonstrated  that  the  model  charaee tittle* 
tan  be  thoroughly  atudied  and  correlated  to  the  benchmark*  of  Individual 
procedure*  and  task*,  further,  the  task  Interaction*,  task  overhead  and  the 
effect  0<l  the  throughput  wilt  be  analyzed  by  comparing  a  Sequential  model 
to  a  parallel  tasking  model.  Poe  time  Critical  multi-tasking  processes  thi* 
Jtudy  suggest*  that  a  rapid  model  simulation  In  Ada  on  VAX  provide* 
quiet  Identification*  of  lime  critical  legion*,  an  undemanding  of  model 
behavior*  and  allow*  the  designer  to  tailor  the  model  for  the  belt  timing 
performance  prior  to  target  implementation. 


l^lSTKOlH’gTlON 

The  procesic*  studied  t  Figure  1 1  involve  the  sorting  of  radar  pulse*  that 
have  been  digitised  and  sampled  to  produce  a  N-byie  feature  vector  T!k 
algorithm  consist*  of  a  closed  loop  decision  process  that  compares  cadi  of 
Ihc  24  feature*  to  known  libraries  of  feature  vector  llmita  tn  search  of  a 
'beat  fit*  The  best  fit  u  identified  In  term*  of  a  feature  slot  identification 
number  tl.O  t.  Cluster  analysis  ts  used  to  identify  signals  that  do  not 
correlate  with  canting  libraries  citlKl  due  to  new  signal*  introd treed  into 
the  system  or  old  signal*  whose  fcatute*  may  be  drifting  because  of 
environmental  change*.  In  order  to  keep  track  of  the  coohnuou*  processes 
of  clustering  and  producing  statistically  generated  mean  feature  vectors, 
the  processes  were  written  in  name  MC6S010  assembly  language  (ASM  a 
As  a  result.  iIk  ASM  working  with  custom  built  hardware  la  able  to  mccl 
tbe  leal  time  requirement  when  running  tn  an  embedded  6S01Q  target 
iTGTt.  T1k  24  featurea  obtained  via  duster  analysis  are  used  to  set  new 
WAM  t  window  addressable  merooty  t  limits  or  to  update  old  WaM  limits. 
Each  WAM  slot  provides  24  feature  limits  to  allow  pattern  matdiing  with 
the  present  signals,  'flie  whole  processes  cycle  until  all  WAM  slou  are 
set.  At  least  two  task*  are  needed  to  handle  Uk  asyndtronous  processes  • 
an  NS  task  to  handle  new  signals  and  an  AS  task  to  adapt  to  drifting 
signal*  Both  task*  rely  on  input  signal  thus  inquiring  two  more  tasks  •  a 
DMA  task  to  input  feature  vectors  through  direct  memoty  access  and  a 
SYNCHRONIZATION  task  to  syncluoruze  all  three  tasks  while  causing 
DMA  to  stay  one  buffer  ahead  of  NS  and  AS  This  arrangement  allows 
the  overlap  of  data  I/O  with  CPU  eaecutior.  and  ensures  that  buffered  data 
does  not  become  outdated. 
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f  igure  I  Functional  Block  Diagram  of  the  Iboc cases 


In  addition  ta  tasks,  a  doubly  linked  list  is  used  as  the  basic  data  atrocture 
by  the  process  model.  Tills  structure  suits  tbe  dynamic  nature  of  the 
signals  while  providing  pointer*  for  direct  data  access.  Whenever  NS  or 
AS  accumulate*  enough  link*  from  the  Input  buffer,  signal*  on  the  linked 
lilt  are  lotted  Into  a  hash  table  to  speed  up  clustering.  Then  signal  links 
wiilr  smalt  feature  differences  start  in  duster  by  joining  fcatute*  of  sub* 
duster*.  To  avoid  waning  lime  in  garbage  collecting  Uk  used  link*,  the 
model  allocate*  sufficient  free  link*  from  the  heap  Own  control*  tbe  link 
allocation  and  deallocation.  In  order  to  share  the  global  link  pool  between 
NS  and  AS  tasks,  a  FREE, POOL  task  ha*  to  be  added  to  guarantee  that 
the  pool  access  is  mutually  cadiutvc  Fig  are  2  depicts  i!k  relatioudtip  of 
IIk  Lre  task*  tn  the  model.  To  implement  tasks.  ASM  was  written  around 
a  popular  ‘off-ihe-shelF  real-time  operating  system  (O.S-.I.  Ada.  on  iIk 
other  hand,  has  concurrent  programming  facilities  which  provide  the 
notational  convenience  and  conceptual  elegance  in  writing  concurrent 
algorithm*  inherent  in  this  model  Figure  J  depicts  the  Ada 
implementation  of  the  model  in  five  package*,  the  dependency  of  the 
package*  and  the  entry  call*  made  by  tic  parallel  task*. 

tn  the  process  to  determine  how  close  Ada  meets  the  teal  time 
requirement,  we  encountered  the  following  difficulties  when 
be  net  im  irking  both  Ada  and  ASM  onTGT : 

(1)  ASM  bcnclimaik  -  benchmatks  of  procedures  directly  related  lo  I/O 
ate  not  measured  since  I/O  ts  a  machine  dependent  variable 
Meanwhile,  timing  of  the  task  overliead  can  not  be  done  without 
cnangtng  the  source  code.  Tlierefore  less  than  half  of  die  procedures 
are  benclimatkcd  and  no  tlirou ghputs  are  measured.  Moreover,  tlie 
dynamic  behavior  of  the  procedure  is  not  always  known  because 
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event*  happening  within  the  procedure  tan  ne(  be  traced  during 
benchmark,  Thu  u  funher  Cffrapikncd  by  the  fao  that  itigto  thu 
vaitaiioex*  will  0<cur  due  10  touadto g  to  Ihc  A/I)  Convener  The 
rounding  error  is  sufficient  to  ciuk  completely  different  model 
Ktu»i«  evs » run  to  run  basis 

t2l  Ada  benchmark- TSA0A/E6*crn«*ce<«fikf  is  found  to  be  able  to 
handk  three  task*  but  hot  ad  five  u»U  needed  by  Ok  pruevMe*  (this 
problem  ***  fl>ed  to  *  latter  version  J.lSk  Despite  various  like, 
caccutlon  of  the  ft  re- tut  model  jdwsyi  g*u  aborted  root  entering 
the  mutd-tuklng  >u  gc  Without  attempting  other  com  piled.  we 
analysed  the  parallel  model  and  detetmtoed  that  it  can  he 
scqucniistircd  by  modifying  the  top  mou  hierarchy  of  the  entire 
structure  Other  than  the  procedure*  that  replace  the  talk*,  all 
remaining  procedure*  atay  the  lame  for  the  two  model*.  Therefore 
benchmark*  of  the  common  procedure*  ahould  he  die  *arac  for  hurh 
model*. 

figure  4  describe*  the  major  difference*  between  the  parallel  model  and 
the  scquentUI  model,  to  the  »equenti*l  model,  die  MAIN  program  tamed 
to  lean  the  input  buffer  If  the  algnal  rearmed  l*  near  then  MAIN  *111  call 
NS  for  linking  etae  it  *111  call  AS  for  linking.  After  all  buffer  *ignal*  ate 
scanned.  MAIN  *111  call  DMA  10  fill  the  neat  buffer  ahead.  On  the 
contrary,  to  Ihc  parallel  model  both  NS  and  AS  *can  the  «ame  bv'fer 
Independently  whik  DMA  ruru  almultancouily.  Although  both  mtecl* 
lake  the  *ame  Input  and  generate  the  *amc  output,  their  timing 
petfotmanee  may  differ  signlficandy. 

Although  benchmark*  of  ASM  and  Ada  can  he  done  to  TOT.  they  both 
encountered  reatiietiont.  To  get  around  the  problem  *c  benchmarked  the 
proceu e*  on  a  self-targeted  machine.  VAX/1600  (VAX),  *herc  the 
TSADA/VMS  compiler  I*  able  to  handle  both  model*  propeily.  When 
coding  Ada.  instead  of  replicating  ASM  *icp  by  atep,  *e  u«e  Ada  feature* 
to  implement  the  e«julv»knt  ASM  function*,  Processes  tun  On  VAX  *iit 
not  be  able  to  ten  the  hardware  I/O  used  otsTGT,  but  *111  provide  the 
deaigner  tlx  convenience  to  lime  and  analyte  high  kvcl  algorithm*  of  the 
model,  and  to  have  full  control  of  the  Input  data,  Input  data  can  be 
synthesised  by  a  iimulatioa  program  or  converted  from  binary  data 
collected  from  antenna*.  When  benchmarking  procedure*  of  parallel 
proce**e*.  tlx  time  alicing  feature  I*  diublcd  to  order  to  prevent  talk 
preemption  or  **apping  from  Interfering, 

Tlx  atudy  I*  summit  tied  to  the  following  lection*.  System  letup  and 
timer*  such  a*  logic  analyzer.  system  clock  (SYS  elk),  Ada  clock  (Ada 
elkl  and  target  dock  (T OT  elk)  ate  presented  to  section  I  of  the  paper. 
Section  1  discusses  timer  characteristic*,  model  behavior,  benchmark 
result*  and  model  comparisons,  while  Section  4  presents  our  conclusions. 
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Figure  1  Tasking  Structure  of  ihc  Parallel  Model 
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3  SYSTEM  SETUP  AND  It £NC1  (MARK  TOOLS 

2.1  System  Setup 

Since  tlx  benchmark  nxisure*  both  machine  arthixeture  and  the  ability  of 
tlx  compiler  to  generate  efficknt  codef  1 .4  J.  major  system  configurations 
of  VAX'S 600  and  TCT/6S0I0  are  listed  to  Table  I. 

2.2  Benchmark  Tools 

2-2.1  ASM  on  Embedded  TOT 

The  6S0I0  code  wa*  assembled  on  a  Kontron  Development  System  then 
downloaded  onto  the  TOT  operated  under  an  UNIX  like  O.S. .  PSOS. 
When  benchmarking,  the  HP-1630A  logic  analyzer,  HP-1031 1 1)  interfice 
probe  and  HP- 10269C  preprocessor  were  used  to  provide  precise  timing* 
between  trigger  point*. 


Figure  3.  Ada  Package  Construct  of  the  Parallel  Model 
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Figure  4.  Parallel  MoJel  vs  Sequential  Model 
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tw^dfedTirr 

The  A  ill  csreution  tmUrwtM  b**|obe  nui^  and  adapted  19  the 
machine  dependent  port  (ant  p(  the  TOT  Including  ctxvtolc  If©.  deck 
cwutW.  interrupt  handier  and  exception  lafck  To  alto*  bcnchmaeking,* 
icMttlM  which  controls  *  programmable  countdown  timet  tfTM 
MOolMCt})  w»*  added  to  ihc  Ads  environment  module  Then  the  Ad* 
code  wm  crows  compiled  on VAX  by  T5ADA/E4*  *«d  the  tesakin  g  5« 
trewdt  were  downloaded  entoTttT  Start  the  Ada  executive  kernel  hv< 
been  linked  into  the  download  module.  the  TOT  I*  treated  utlstK 
machine  wfcht-q  need  efdieceigiA*l  05. 

?'-,-'4s.'y,.v.AN 

The  A>t»  ««k  im  compiled  v(*  TSAOAA’MS  compiler  on  VAX  then 
benchmarked  on  VAX  using  SYS  elk  SYS  elk  called  (tom  *  Fortran 
routine  provide*  belief  meMutcmcnlt  than  A4*  elk  c*Ue4  ft  cm  the 
Calendar  package:  although  pen*bd«ty  at  SYS  elk  H  ronkicd  to  machine* 
of  VAX  Kite*.  tM*c  the  logic  analyser,  neither  TOT  elk  art  SYS  elk 
provided  liming  accuracy  »t  the  nanosecond  k*e  I  that  a  timing  loop 
technique  »»t  med  in  iwptnvt  the  »ec«t»e y  of  both  eioekt  The 
bcnchmaih  of  a  procedure  ww*  obtained  by  subtracting  the  benchmark,  of  a 
control  loop  from  Out  of*  ic*t  lenpflj. 

Poe  all  A4*  wendens,  *tge*l  4*1*  were  MtUtircd  in  memory  In  otdef  in 
minimise  the  to  lime  spent  in  tfceeughput*,  Meanwhile  nn  eptimlraiim 
W  invoked  in  ttMtt  the  proper  bcnehm*tijng{;| 
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Among  the  4nec  etoek*  of  Ad*  elk,  SYS  elk  and  TOT  elk,  Table  2  show* 
slue  TtjT  elk  ha*  the  highest  rraohstten,  the  )owc*<  overhead  and  the  tcaat 
interference* 

One  in  the  high  rcjolurion  of  SYS  elk  and  ihe  slownr**  of  ihc  Cteu 
tom  piled  Ad*,  the  benehmaiii  of  Ad*  on  TOT  were  obtained  without 
looping  in  noil  cases  To  be nchma«k  on  ihc  VAX,  we  choose  SYS  elk 
became  It  offer*  a  201b  belief  resolution  than  Ada  elk  and  SYS  elk 
mem  me*  CTU  lime  only.  Notice  that  the  CTU  lime  of  a  ptocts*  it  alill 
affected  by  page  thrashing  or  swapping  from  ihc  O.S.(2  j]  However, 
tacetaive  page  thrashing  {*  unlikely  lo  occur  under  a  ling k  user  condition 
during  benchmarking  although  some  wilt  occur  lo  allow  the  O  S  la 
perform  minimum  system  service*.  Rcnchmaekt  cm  the  dedicated  TGT, 
however,  are  not  Inter  feted  by  Ihe  system  si  sny  lime.  System 
Inlctfettnces,  reflected  oy  the  standard  deviation  (5TDEVJ  of  the 
measurement  mean.  Is  near  0%  for  TOT  elk  and  lea  than  2%  for  SYS  elk. 
Interferences  of  VAX  system  work  load  on  both  Ada  elk  and  SYS  elk  are 
displayed  in  Figure*. 

3  2  Benchmark  Ucaultt  on  TOT  and  VAX 


Tabk  3  shows  the  benehmatk  comparisons  of  parallel  Ada  vs  sequential 
Ada  on  VAX  and  sequential  Ada  vs  parallel  ASM  on  TOT.  Benchmarks 
ranging  from  7  ewe  lo  1,2*0,000  utec  ate  apedfkd  for  procedures  or  tasks 
that  am  indented  according  to  Ihcir  hierarchical  calling  sequence.  To 
5 void  repealing,  we  elaborate  the  sequence  only  when  ihc  procedure  is 
first  encountered.  In  comparing  the  Iwo  Ada  models  on  VAX, 
benchmarks  are  listed  according  to  procedures  that  are  common  to  both 
models  and  unique  to  each  model.  Among  the  benchmark  differences,  tic 
parallel  model  eahlbics  a  much  slower  throughput  than  the  sequential 
model  because  of  the  task  overhead.  Meanwhile,  the  ASM  benchmarks, 
though  limited,  indicate  that  ASM  run*  roughly  10  times  faster  than  the 
cross  compiled  Ada  on  TOT.  Therefore  we  conclude  that,  If  the  parallel 
model  used  by  ASM  were  coded  in  Ada,  the  efficiency  of  the  Ada  parallel 
model  will  be  more  than  10  time  slower  than  ASM. 
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Figure  5  Effect  of  VAX  System  Work  Load  on  Adi  elk  &  SYS  elk 


In  ASM,  the  computation  pan  of  CALC_WAM_UMITS  procedure  Is 
operated  via  filed  point  math,  mainly  by  shifting  bits.  In  order  lo  preserve 
the  accuracy  while  calculating  the  means  and  standard  deviations  of  the  2* 
features.  To  code  the  same  function  in  Ada  both  the  long-integer  method 
and  the  fiacd-point  method  are  feasible.  The  long-integer  method 
preserves  the  accuracy  by  simulating  bit-shifting  vis  multiplication  white 
Ihe  fiaed-point  method  does  it  automatically  via  type-casting.  Altliough 
the  fiacd-point  method  is  easier  to  implement,  its  execution  lime  of  $S2 
usee  is  24%  longer  Ihe  794  uscc  of  the  long-integer  method  on  VAX. 
Thus  we  choose  the  long-integer  method. 
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33*  1 

1«« 

♦  4 

DEALLOC  USES  EEC 

11  1 

33 

— 

PEEE  PCOL.DEAUOC  USED  EEC 

1  1197 

—  | 

— 

44 

AS_PUECE  (MlHIWUMl 

1  333 

—  1 

— 

44 

4.1.  SET_HXT_»Ur_IXX 

•  4  1 

943 

— 

4.1.  SYHCHROHIXATICX  TASK 

I  1247 

—  1 

— 

♦  ♦ 

icctft  ns_w  quest 

i 

ACCEPT  AS  EE5UEST 

i 

ACCEPT  DMA  DONE 

i 

SET_XXT_BUr_IHX 

1  14 

—  1 

— 

4+ 

3.  rEEC_POOL  TASK 

l 

ACCEPT  ALLOC  HEW  EAC 

|  1190 

..  | 

__ 

44 

ACCEPT  DEALLOe_USEO_EEC 

1  1179 

- 1 

— 

44 

•  FAKALL XL  ••  SEOUEHTIAL  —  HOT  APPLICABLE  +4  HOT  KEASOBXO 

*  MEASURED  AT  CCHOITIOHS  SPECIFIED  TO  THE  LETT 


TABLE  X  BENCHMARKS  OF  ADA  ON  VA.Y  *  TCTAND  ASM  ON  TOT 
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3.4  Tmkint  Overhead 

The  tasking  feature  of  Adi,  tho«fh  powerful  In  providing  concurrent 
solutions,  li  severely  tendered  by  in  run  time  performance.  While  a 
procedure  call  Invoke*  the  lave  and  rcalort  of  the  return  addtc**  and 
re*l«*eni  rued,  a  ude  entry  call  Invoke*  the  more  cawmlve  contcar  switch. 
During  die  switch,  the  old  task  I*  preempted  and  It*  corneal  layer  laved 
then  a  new  iuk  U  selected  and  It*  conceal  layer  restored,  Since  a  conteal 
layer  ll  the  laak  eaecut  Ion  environment.  It  Include*  acli  of  rtf  liter*  and  all 
local  variable*  used  by  rhe  talk.  On  both  TOT  and  VAX,  Table  4 
demonstrate*  that  laak  entries  called  in  panllel  model  consume*  30-100 
fold  mote  lime  than  procedure*;  called  in  sequential  model.  Moreover,  the 
actual  work  conducted  within  the  ALLCC_NUW_RfiC  and  the 
D EA LLOC.US E D_R EC  entries  of  (he  FREE.POOL  |a*k  i*  minor. 
Nevertheless,  the  two  entries  arc  needed  in  order  to  g uarantcc  the  mutual 
esdusive  access  of  the  (lobsl  free  pool  between  NS  and  AS  Usk*.  if  NS 
and  AS  iteep  their  own  free  pool,  the  FREE. POOL  task  can  be  eliminated 
toward  the  benefits  of  the  process  efficiency. 


TARALLEL  SEO*»  RATIO 


l  or 

TASKS 

ENTRY, 

VTIKC  IN 

CALL, 

ENTRY/ 

VAX  STHCHROH12EO 

USEC 

ENTRY 

USEC 

CALL 

SYMCHR0NI1ATIQH 

3 

1247 

9.5k 

0 

— 

ALLOC  HEM  AXC 

2 

1190 

1.5k 

17 

70 

OEALLOC_UJEOJIEC 

2 

1X77 

2.7k 

11 

107 

TCT 

SYNCHRONISATION 

3 

2040 

Ok‘ 

0 

— 

ALLOC  HEM  REC 

2 

3310 

Ok 

70 

48 

DE ALLOC  USED  REC 

2 

3380 

ok 

32 

106 

•  TOT  ICHCWtARXS  ARC  OHTAIHCO  TRCtt  SIMULATION  Hint 
HULL  STATEMENT  INSIDE  ENTRY  •*  SCOUtHTIAL 


TABLE  V.  TASK  OVERHEAD  -  ENTRY  CALL  VS  PROCEDURE  CAIL 


3.3  Throuthput  and  Suppression 

The  average  lime  needed  10  update  the  24  features  of  I  WAM  slot,  defined 
as  throughput,  by  NS  and  AS  tasks  arc  compared.  Table  3  Indicates  that 
the  sequential  Ad*  model  runs  10  limes  slower  on  TGT  lltan  on  VAX. 
Meanwhile,  on  VAX,  the  task  overhead  associated  with  the  parallel  model 
makes  ll  run  30%  slower  than  the  sequential  model,  and  the  percentage  of 
being  slow  increases  after  suppressing  all  run  time  check*.  By  catling 
i-'REE.POOL  risk  less  often,  AS  invoke*  less  task  overhead  Ilian  NS.  On 
the  other  hand,  AS  consume*  30-100%  more  lime  in  throughput  than  NS 
even  when  AS  uses  simpler  algorithm.  Benchmarks  of 
CLUSTER.DISTANCE  procedures  from  NS  and  AS  indicate  that  this  is 
because  AS  collects  twice  as  many  signal*  and  the  time  spent  in  pairing 
signals  for  feature  difference  increases  by  the  power  of  two. 


NS 

NS 

AS 

AS 

AS/NS 

cru  MOOEL 

USEC 

RATIO 

USEC 

RATIO 

RATIO 

unsuffressed  VERSION 


VAX 

PARA* 

101923 

1.60 

172500 

1.37 

1.69 

VAX 

SEQ** 

60692 

1.00 

125500 

1.00 

2.07 

TCT 

SEQ 

607803 

10.01 

1238067 

9.87 

2.04 

SUPPRESSED 

VERSION 

VAX 

PARA 

90130 

1.91 

135000 

1.41 

1.50 

VAX 

SEQ 

47231 

1.00 

95000 

1.00 

2.01 

TCT 

SEQ 

561488 

11.89 

1123043 

11.82 

2.00 

•  PARALLEL  •*  SEQUENTIAL 

TABLE  S.  NS  A  AS  THROUGHPUT  -  SUPPP.ESS  VS  UNSUPPLESS 


For  better  efficiency,  all  Ada  run  time  check*  arc  suppressed  and  the 
result*  are  displayed  in  Table  6.  The  suppressed  versions  art  able  to 
decrease  the  memory  sire  of  the  executable  code  by  3%.  and  to  increase 
rhe  throughput  by  10-23%  depending  on  the  model  and  the  machine  on 
which  it  runs. 


TRQCESS 

cru 

HOOEL 

MEMORY 

TIME 

NS 

VAX 

TARA 

4.1k 

11.  <k 

A3 

VAX 

FARA 

5.2k 

21.7k 

NS 

VAX 

SEQ 

1.0k 

22.2k 

AS 

VAX 

SEQ 

4.9k 

24.3k 

NS 

TCT 

SEQ 

5.4k 

7.6k 

AS 

TCT 

SEQ 

5. 4k 

9.3k 

TABIX  fi.  MEMORY  AND  TIME  SAVED  B  Y  SUPPRESSION 


X6  Benchmark  Equation  Derivation 

Since  both  models  arc  dynamically  driven  by  I/O,  benchmarks  of  I/O 
dependent  procedure*  appear  to  be  random  at  first  glance.  However,  by 
matching  benchmarks  with  activities  traced  fiom  a  program  independent 
of  the  benchmark  study,  wc  are  able  to  relate  the  benchmarks  to  events 
that  occur  dynamically  within  the  procedure  and  to  formulate  the 
benchmark  into  an  event  equation : 

benchmark  *  deviation  4  sum  of  ail 

(sub-procedure  benchmaik  *  »  of  calls). 

where  deviation  reflects  the  measurement  error  (<l%,Table  8)  or 
procedure  overhead  (Tables  7,9.10).  Tabic  7  shows  a  simple  example  of 
procedure  CIuslcr_Dln*nce  of  AS  task  making  49$  calls  of  DIFF  sub¬ 
procedure.  The  difference  between  the  measured  benchmark  923010  usee 
and  the  calculated  DIFF  benchmark  iota).  49$  *  1863  usee,  results  in  a 
deviation  of  927  usee  on  TGT.  Similarly  the.  deviation  Is  calculated  lo  be 
1694  usee  on  VAX.  Tables  8  and  10  describe  lha!  more  complicate 
equations  can  be  formed  for  procedure*  whose  individual  benchmarks 
vary  with  the  number  of  sub-procedures  called  during  each  measurement. 
Table  9  *l>ow*  a  procedure,  though  makes  no  sub-proecdurc  calls,  whose 
benchmark  Is  directly  related  lo  the  number  of  WAM  set.  Equations  thus 
derived  allow  tun-time*  lo  be  predicted  unde'  various  conditions  without 
actual  benclmiariung. 


3.6. 1  O.USTEK_DlSTANCF.  called  by  AS 


AD A/TOT 
USEC 

IOF  DIFF 
CALLS} 

DEVIATION 

USEC 

ADA/VAX 

USEC 

DEVIATION 

USEC 

92S009.9 

496 

927.2 

99158.3 

1694.3 

5  -  tll-(N-l)/2)  WITH  N  -  4  OF 

LOCI CAL  LINKS  -  32 

TABLE  7.  CLUSTERJHSTANCE  CALLED  BY  AS 


CLUSTER  DISTANCE,  USEC  -  DEVIATION  + 

HOP  DIFF  CALLS)  •  (DIFF  BENCHMARK) 

-  927.2  +  lHMH-O/2]  •  1863. 1  --  ADA/TCT 

-  1694.3  +  ()!•  (H-1J/2)  •  196.5  —  ADA/ VAX 


Because  of  tlte  high  calling  frequent.  •  of  DIFF  by  CLUSTER_DISTANCE 
procedure.  DIFF  consumes  99%  or  live  CLUSTER_D1STANCE  lime  on 
both  VAX  and  TGT.  If  DIFF  were  coded  in-line,  DIFF  will  become  19% 
more  efficieni  on  VAX  but  only  1%  more  on  TGT. 


136  7th  Annual  National  Conference  on  Ada  Technology  1989 


jai  qAtyrr-K-nisTANcn  caiku  by  ns 


1(3  NS  CXt'.’nTJt  called  bv  NS 


ADA/TCT - ter  CALLS - DEVIATION  ACA/VAX  DEVIATION 


USEC  RESET* 

oirr 

•  INSERT* 

USES 

USEC 

USEC 

191(7.4 

1 

43 

43 

130.0 

1P230 

173.4 

131144.3 

1 

70 

42 

45.7 

14435 

-30.7 

1092(0.2 

1 

33 

33 

94.9 

12330 

132.4 

107(33.9 

1 

33 

11 

1(0.1 

110(0 

109.4 

1290(3.0 

1 

(« 

4« 

41.3 

14230 

31.1 

131910.2 

1 

70 

sc 

-104.1 

14(40 

-74.9 

121177. « 

1 

44 

30 

403.  ( 

13930 

33.9 

131309.1 

1 

70 

70 

-121.9 

17000 

•44.3 

131473.1 

1 

70 

40 

-43.2 

14330 

•42.3 

1731(3.  4 

1 

91 

31 

-««.( 

19040 

-140.4 

1320(7.2 

1 

70 

SC 

-17.1 

144(3 

-49.9 

130023.0 

1 

70 

30 

7.9 

14333 

-79.5 

13201C.C 

1 

70 

3( 

-47, < 

14703 

-29.9 

109240. C 

1 

33 

35 

03.4 

123(0 

144.2 

120011.4 

1 

(( 

30 

114. 4 

13930 

13.9 

133390. < 

1 

70 

70 

-94.3 

17095 

•31.3 

09991.0 

1 

43 

43 

1(2.5 

10233 

200.4 

120331.4 

1 

44 

34 

134.0 

14040 

34.7 

17(933.0 

1 

91 

(7 

-143.3 

19310 

-173.2 

130000.0 

1 

70 

30 

-17.1 

14330 

-44.3 

HZAi  1  - 

39. ( 

4.4 

STBEV  « 

143.1 

104.1 

reset*  -  reset_scrtiho_tbl  oirr*  -  oirrtwiiss 

INSERT*  -  )NSEAT_SCRT1NS_T8L 

TABU!  8.  CLUSTER J)ISTANCE  cauxd  BY  ns 


AOA/VAX 

—  HIT  FALLS” 

•or  HAM* 

DEVIATION 

USE? 

RETN* 

LIMITS* 

SET 

USE? 

432.7 

7 

0 

0 

131. 0 

1099.3 

12 

1 

0 

229.0 

407.3 

10 

0 

0 

133.4 

1942.0 

9 

1 

1 

100.2 

544.7 

9 

0 

0 

133.2 

2300.7 

11 

1 

2 

241.0 

2407.3 

9 

1 

3 

219.1 

1 20.7 

10 

0 

0 

144.9 

2422.0 

9 

l 

4 

214.3 

474.7 

11 

0 

0 

174.4 

2077.3 

10 

1 

3 

210.3 

3104.0 

10 

1 

4 

221.7 

3420.0 

12 

1 

7 

237.9 

530.7 

9 

0 

0 

141.2 

3411.3 

9 

1 

< 

207.0 

3903.3 

13 

1 

9 

234.3 

301.3 

1 

0 

0 

134.2 

517.3 

1 

0 

0 

132.2 

4032.0 

11 

1 

10 

234.4 

4240.7 

11 

1 

11 

234.0 

KEAN  - 

194.0 

STOEV  - 

30.0 

RETN*  -  RETNJASICAL  ARC 
LIMITS*  -  CM/Tw*>i_LIhTtS 

VAM*  -  <  Or*"wAM~ SET  IK  IS_NEM_CLUST£R  CALL 


CLUSTER_0!STANCE,USEC  -  DEVIATION  4  (RESET  BENCHMARK)  ♦ 


uor  oirr  calls) 

(•OF  INSERT  CALLS) 

«  39.4  ♦  2122*4  ♦  (»or  oirr  calls) 
(•or  INSERT  CALLS) 

•  «.«  •  411.1  4  uor  oirr  calls) 

(•or  INSERT  CALLS) 


(Oirr  BENCHMARK)  4 
(INSERT  BENCHMARK) 
1043.1  4 

TO. 4  —  AD  A/ TOT 

ISS.S  4 

17. 1  —  ADA/VAX 


J.M  IS  NEW  CLUSTER  called  by  NS 


TABLE  10.  NSJCLUSTER  CALLED  BY  NS 

N3_CLU3TER,USEC  «  DEVIATION  4 

(•Or  REIN  CALLS)  •  (RETN  BENCHMARK)  4 
(•Or  LIMITS  CALLS)  •  (LIMITS  BENCHMARK)  4 
(I5_NEN_CU)STER  BENCHMARK) 

-  194.0  7  (»or  RETN  CALLS)  •  44.3  4 

(•OF  LIMITS  CALLS)  •  1127.2  4 
10.7  4  (JOT  MAM  SET)  •  217.2  —  ADA/VAX 


MAH»  ADA/TOT  USEC/  AOA/VAX  USEC/  ASH/TOT  USEC/ 


SET 

USEC 

HAM* 

USEC 

HAM* 

USEC 

HAM* 

0 

42.9 

.. 

10.7 

.. 

21.1 

1 

3102.1 

3139.2 

224.7 

214.0 

100.3 

1(7.2 

2 

(317.4 

3137.3 

444.0 

217.7 

339.3 

149.1 

3 

9454.4 

3137.9 

(43.3 

217.4 

542.0 

173.4 

4 

12393.0 

3130.2 

001.3 

217.7 

3 

13731.2 

3137.7 

1094,0 

217.1 

4 

10047.0 

3137.3 

1312.0 

214.9 

7 

22009.4 

3130.1 

1332.0 

217.3 

a 

23143.0 

3137.5 

174(.7 

217.0 

9 

20204.2 

3137.9 

1947.3 

217.4 

10 

31420.0 

3137.0 

218C.7 

217.4 

11 

34*43.2 

3130.2 

2400.0 

217.2 

12 

37(92.2 

3137.4 

2(10.0 

217.3 

KEAN  - 

3137.9 

217.2 

170.0 

STOEV  - 

O.S 

0.5 

3.5 

•  M 

(BENCHMARK  AT  HAM4N 

-  BENCHMARK  AT  HAM40) 

/  IN 

TABLE  9.  ISJJEWjCLUSTER  CALLED  BY  NS 


NS_CLOSTER,USEC  -  DEVIATION  4 

(»0F  MAM  SET)  •  (HAM  BENCHMARK) 

-  42.9  4  3137.9  *  (»0F  HAM  SET)  —  AD A/ TOT 

-  10.7  4  217.2  *  (40F  HAM  SET)  —  ADA/VAX 

-  21.1  4  170.0  «  («0F  HAM  SET)  —  ASM/TOT 


3.7  Empirical  Factors Correlating  Benchmarks 

Since  VAX  benchmarks  ate  readily  available,  we  suspcci  lliat  TGT 
benchmarks  may  be  correlated  lo  VAX  bendunarfcs  via  empirical  factors. 
When  a  benchmark  comparison  is  made  on  different  processors  or 
different  systems,  the  empirical  correlating  factors  become  a  gross 
measurement  of  language  influence,  compiler  influence,  machine 
architecture,  cache  Influence,  etc, (1, 4).  These  factors,  however  rough, 
allow  the  designer  to  guess  lire  approximate  timing  pcrfonnancc  of  the 
model  and  possibly  tune  the  model  before  embarking  on  a  full  scale 
benchmark  study  on  TGT.  Since  only  lire  sequential  Ada  model  runs  on 
TGT,  we  tested  its  benchmark  correlation  to  the  same  model  run  on  VAX. 
Table  1 1  lists  lire  resulting  factors  correlating  Ada  procedures  of  similarly 
features.  Tire  correlation  is  then  tried  between  benchmarks  of  Ada  and 
ASM,  both  run  on  TGT,  and  finally  between  Ada  on  VAX  and  ASM  on 
TGT,  Results  of  lire  two  sets  of  correlations  are  shown  in  Table  12.  To 
lire  thirteen  benchmarked  ASM  procedures,  only  those  that  are  not  hand 
optimized  and  are  using  tire  lame  data  structure  and  algoritlun  as  lire  Ada 
code  can  be  used.  Based  on  the  six  qualified  procedures,  the  factor 
correlating  Ada  on  VAX  and  ASM  on  TGT  is  estimated  to  be  1.0(+/-0.25). 
Tire  designer,  however,  is  cautioned  to  use  the  factor  only  for  codes 
intended  for  similar  purpose  and  developed  under  lire  same  systems. 
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kmx  ttxvm 


mcetK’KS 


rACTOR.TCT/VAX 

KEAXlSTtSEV) 


CCXERAL 

DKA.  XS  S  A3  TXAOOSHPtJT.  XS  t 

AS  CLUSTERED! STANCE, 

DIITSRtNCE,  SCT_XXT_#Vr_lXX 

9.3(0.4) 

pointers 

XS  *  AS  LINK  LOGICAL  PHYSICAL 

RE*.  RETS  LOGICAL  LINK,  CET_ 
LOCICAL  RE*,  INSERT JtSRTIIH  T8L. 
RE5tT_SSATINS_T9L 

s. an. si 

LCX'3  IXTX- 
CER  HATH 

CALe_WAJ|_LIK!TS.  AS_CLUSTER 

1*. Tto.il 

MEMORY 

ACCESS  l  rtJLSE  rROt  MEMORY.  !S_ 

A’CESS 

NEW_CLUSTER.  UfOATtJHA8_LIMlTS 

14.3(1.1) 

TABLE  II.  COBREUTE BENCHMARKS  OFADAIVAXTOADAITGT 

■i.  conclusion 

In  spile  of  limitation  encountered  In  benchmarking  parallel  ptoeeuei  on 
TGT.  we  arc  »blc  lo  demonstrate  that  ui!n|  Ada  on  VAX  allow*  rapid 
model  simulation  of  mat  lime  prtxcucs  and  quick  profiling  of  the  proem 
performance.  Without  I/O  rcxtrfcticw  and  lengthy  downloading  lime,  ltd* 
approach  encourage)  the  detlgner  to  try  different  model  cctuinicu  and 
language  feature)  In  aeatch  of  a  mo<lcl  with  deilted  characteristics  and 
required  timing  performance.  Further,  the  arudy  shows  that  benchmark*  of 
dynamic  processes  can  be  formulated  Into  event  equation*  lo  allow 
benchmark  prediction.  It  alao  suggests  that  an  empirical  factor  may  relate 
the  VAX  benchmark  to  the  TOT  benchmark  although  more  work  need*  to 
be  done  to  confirm  *ueh  a  relationship.  Finally,  on  the  embedded  TGT, 
the  teal  time  performance  of  the  croti  compiled  Ada  I*  not  yet  close  to 
that  of  ASM  which  strive*  to  take  advantage  of  the  underlying  hardware 
and  language  constructs  for  efficiency. 


KAJOR  rtATURE 

PROCEDURES 

TOT/ VAX  ASM/VAX 
TACTCR,  KEAH(STOEV) 

assicxkents  a 

rOINTERS 

R1TH  CLUSTER  INX, 

cet_cluster_7nx, 

REStT_SORTINO_T»L, 

1H:ERT_50RT1N0_T»L 

3. 0(1. 3) 

i.:(0.2) 

MEMORY  ACCESS  a 
SIKTLE  MATH 

DirrERENCE, 

IS^NEW_CLUSTER 

13. 3(1. <| 

O.I(O.l) 

COMBINED  RATIO 

1.0(0.23) 

TABLE  II.  CORRELATE  BENCHMARKS  OF 
ADAITGTTOADAIVAXANDASMITOTTOADAIVAX 


3.8  Module  Sire*  and  Kate  of  Modeling 

Table  13  compare*  lire  code  lire*  of  Ad*  and  ASM  both  run  on  TGT.  For 
a  fair  comparison  lire  Ada  code  I*  compiled  under  conditions  similar  lo 
ASM  with  no  run  lime  check*,  no  TEXTJO  and  no  pulse  initialisation. 
Punlier,  the  DMA  module  which  simulates  the  Itardware  function  used  by 
ASM  is  excluded  from  the  Ada  code. 
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PARAMETER 


ADA  COOS  MH  CODE 


7.  AUTHORS 


KERNEL/O. S.  SIZE 
EXE  CODE  SIZE 
DATA  SIZE 
SOURCE  CODE 


31  KBYTE 
20  KBYTE 
192  KBYTE 
170  LINES 


S  KBYTE 
3  KBYTE 
8  KBYTE 
21C0  LINES 


•  COtftEHT  LINES  EXCLUDED 


Alice  ).  Lee  is  a  member  of  Information  Systems  group  al  Lockheed 
Electronics.  She  has  implemented  several  rest-time  systems  including 
direction  finding,  gun  fire  control  and  signal  processing.  She  received  an 
M.S.  degree  in  Computer  Science  from  New  Jersey  Institute  of 
Technology. 


TABLE  13.  MODULE  SIZES  OF  ADA  VS  ASM  ON  TOT 


As  expected,  ASM  modules  are  smaller  than  Ada  modules  except  the 
amount  of  tire  source  code.  By  using  the  bit  fields,  the  ASM  is  able  lo 
have  a  data  size  much  smaller  than  that  of  Ada.  If  Ada  were  to  use 
representation  cltuses,  the  data  size  will  decrease  but  code  size  will 
Increase  in  order  to  unpack  the  fields  for  accessing.  Meanwhile,  tire 
readability  and  versatility  of  Ada  makes  the  modeling  concept  easy  to 
realize.  For  example,  the  parallel  model  containing  five  tasks  is 
Implemented  with  10%  increase  or  13%  total  change  on  the  source  code  of 
the  sequential  model  and  with  alt  changes  localized  in  two  of  the  five 
packages. 
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topics.  He  received  a  B.S.E.E.  degree  from  New  Jersey  Institute  of 
Technology. 

Donna  K.  Doi  Is  the  Program  Manager  for  Advanced  Programs  In  the 
Information  Systems  line  of  business  group.  She  has  participated  in  the 
development  of  real  lime  systems  and  Ada  software  development,  She  has 
a  Master's  degree  in  Engineering  from  California  Slate  University, 
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ABSTRACT 

With  206  validated  compilers,  developers 
of  real-tine  embedded  sy seems  need  guidance  in 
the  selection  of  runtine  cnvinxrsnts  (RTEs) 
to  ensure  that  the  KTEs  used  can  sect  strict 
tining  and  storage  requirements.  The  purpoca 
of  this  study  was  to  assist  these  dcvclcpers 
in  the  selection  of  RlEs  by  providing  a  roans 
for  prioritizing  RTE  elements  and  introducing 
the  concept  of  a  corposite  benchmark  to 
evaluate  candidate  RTE  performance. 
Specifically,  this  study  prioritized  RTE 
elenents  and  developed  preliminary 
requirements  for  a  composite  benchmark  for  one 
class  of  systems  supported  by  the  U.S.  Army 
Ccrnunicaticns-Electronics  Oomand  (CECOM) , 
Ft.  Monmouth,  117.  The  class  of  systems 
studied  vas  Oomrunications  and  Electronic 
Intelligence  (CCMDir/ELDlT) . 

This  paper  presents  the  several  steps  in 
the  process  developed  to  prioritize  RTEs. 
These  steps  are  system  selection,  prioritizing 
RTE  dements  and  the  use  of  tho  prioritized 
elements  to  prioritize  grope  of  benchmarks. 
Tho  purpose  of  a  coqposita  benchmark,  the 
development  process  for  such  a  benchmark,  and 
a  preliminary  description  of  a  composite 
benchmark  for  OCKDIT/Eliur  systems  are  given. 
Recommendations  for  the  use  of  benchmarks  in 
RTE  selection  are  redo. 


SY^.SELECTI«Lg-,ERyigw 

The  first  step  was  to  select  o  class  of 
CEOQM  systems  to  analyze.  At  tho  tiro  of  this 
study  CECOM  supported  136  systems.  It  was 
impractical  to  study  all  of  thj  systems 
because  of  tho  system  diversity  and  the  number 
of  systems.  Thus,  the  goal  of  the  selection 
process  was  to  identify  a  class  of  systems  to 
study  that  would  be  most  beneficial  to  CECOM, 
i.e.,  the  class  that  contained  the  most  real- 
time  systems  supported  by  CECOM.  The  specific 
systems  selected  were  representative  of  the 
particular  class. 


The  class  of  system*;  chcocn  were  from  tho 
Battlofield  Functional  Area  (BFA)  of 
Intelligence  Electronic  Karfaro  (IEW); 
specifically,  the  class  of  CCtaKT/ELD.T 
si's  terns.  Tho  systems  that  represented  the 
CCKD.T/EUirr  class  were  Improved  Guardrail  V 
(XGEV),  Communication  High  Accuracy  Airborne 
Location  System  (CHAAIS),  Advanced  Quick  look 
(AQL) ,  and  Trallblazcr  B.  These  systems  were 
chosen  because  they  were  large  and  complex 
real-time  embedded  systems.  An  assumption  was 
made  that  if  a  method  could  be  developed  that 
prioritized  RTE  elenents  (or  largo  and  complex 
real-time  embodied  systems  the  method  could  be 
applied  to  other  real-time  embedded  systems. 


PRIORITIZATreH  OF  THE  PTE  EtittgqS 

Tho  next  step  was  to  prioritize  the  RTE 
elements.  A  prioritization  matrix  was  used  to 
identify  tie  critical  RTE  elements  for 
CCMlinyELmr  systems.  The  prioritized  list  of 
RTE  elements  was  to  be  used  to  prioritize 
berohmarks.  The  axes  of  tho  prioritization 
matrix  arc  emboddod  computer  system  features 
(tho  columns) ,  and  RTE  elements  (the  rows) . 

31E-SIX  SYSTEM _ (KSl 

EEMUBSS 

Tho  Software  Engineering  Institute  (SEI) 
determined  that  there  arc  six  basic  features 
of  an  emboddod  real-time  system;  time 
control,  concurrent  control,  I/O  control, 
error  handling,  numeric  computations,  and 
internal  representation  (Keiderman  1987).  The 
six  features  were  developed  from  a  definition, 
a  general  requirement,  and  basic 
characteristics  of  embodied  computer  si’s  terns. 
The  six  ECS  features  rake  up  tho  columns  of 
the  prioritization  matrix. 

Each  of  tho  features  has  a  weight 
assigixsd  to  it.  The  weights  represent  the 
relative  importance  of  an  ECS  feature  ”ith 
respect  to  tbe  class  of  systems  being  studied. 
The  sum  of  the  weights  must  equal  1031.  The 
1001  signifies  an  entire  system,  and  the 


Support  for  this  research  was  provided  by  AJPO  Contract  Humber 
KDA903-87-D-0056  with  funds  orovided  by  CECOM  Center  for  Software 
Engineering. 
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separata  weight*  indicate  the  importance  of 
each  feature  to  that  system.  Ttw  weights 
should  not  change  as  one  reives  fren  cno  system 
to  another,  provided  one  looks  at  systems  in 
only  one  class.  If  the  class  of  systems  is 
changed,  the  weights  will  change. 

Determining  the  weights  for  the 
CCMrtrr/EUjrr  class  involved  two  steps.  The 
first  was  to  understand  which  features  were 
important  and  to  begin  to  quantify  their 
importance  by  studying  the  systoa 
requirements.  For  this  study  each  requirement 
was  napped  to  the  particular  ECS  feature  to 
which  it  pertained.  Shis  step  resulted  in  the 
majority  of  the  requirements  being  napped  to 
I/O  control. 

This  first  step  gave  an  indication  of 
which  features  were  important  and  wiat  number 
to  assign  as  its  weight.  It  did  not  take  into 
account  issues  that  affect  the  performance  of 
a  system.  The  primary  concern  was  with 
concurrent  control  and  time  control.  iho 
requirements  may  define  the  need  for 
concurrency,  but  they  do  not  represent  the 
solution,  which  is  the  algorithm  that  is  used 
to  moot  concurrency  noods.  Also,  the 
requirements  may  define  the  time  limits 
imposed  on  the  system,  but  they  do  not 
reflect  the  stringency  of  those  limits. 

Step  two  was  to  adjust  the  weights  by 
studying  the  requirements  and  determining 
their  effect  on  the  perforranoo  of  the 
systems.  Then,  taking  into  account  the 
results  of  step  1  and  step  2,  weights  were 
subjectively  assigned  to  each  ECS  feature 
(see  Tablo  l) . 

Table  X 

The  Final  Weights  Assigned  to  the  Features 


Features  weights 

Concurrent  control  201 
Tiro  Control  201 
I/O  Control  251 
Error  Handling  101 
Numeric  Oxput?*~ion  101 


Internal  Repr  itation  151 

IH&.Bffi.Elffafl'S 

The  raws  of  the  prioritization  matrix  are 
the  eleven  FOE  elements.  They  were  obtained 
from  the  document  "A  Framework  For  Describing 
The  Ada  Runtime  Environment"  [ARTEW3  1988]. 
These  RTE  elements  are  the  following: 

Memory  Management 
Processor  Management 
Interrupt  Management 
Time  Management 
Exception  Management 
Rendezvous  Management 


Task  Activation 
Task  Termination 
I/O  Management 

ctmonly  Called  Oodo  Soqocnocs 
Target  Housekeeping. 

The  RTE  elements  rake  up  the  rows  for  the 
prioritization  matrix.  These  elements  are 
assigned  rates.  The  rating  is  for  quantifying 
the  effect  that  an  RTE  element  has  on  the 
performance  of  an  ECS  feature.  Rating  an 
element  against  an  ECS  feature  is  independent 
of  the  class  of  systems  of  interest. 

A  rating  scale  is  used  to  rate  an 
element.  The  foilwing  scale  was  used  in  this 
prioritization  matrix.  Follwing  the  scale, 
each  classification  is  definod. 


Intrinsic  «  9 

Supportive  ■  5 

Extrinsic  ■  1 

Intrinsic  (9):  An  RXE  element  that  is 
foundational  to  the  performance  of  a 
particular  feature. 

Supportive  (5) :  An  RTE  element  that, 
although  not  intrinsic,  has  a  role  in  the 
performance  of  a  particular  feature. 

Extrinsic  (1) :  An  FOE  element  that  at 
meet  has  a  minor  role  in  the  performance  of 
the  particular  feature. 

The  two  documents  previously  cited  were 
influential  in  the  rating  process:  the  ARTEFC 
document,  "A  Framework  for  Describing  Ada 
Runtime  Environments"  (ARTOE  1988]  and  the 
SEI  document,  "Ada  for  Embodied  Systems: 
Issues  and  Questions”  (Weidcrman  1987).  The 
rating  process  involved  concentrating  on  one 
ECS  feature  to  determine  whether  the  clement 
was  intrinsic  to  the  performance  of  the 
feature.  If  it  was,  a  "9"  was  entered  into 
the  square.  If  it  was  not,  the  FOE  element 
was  determined  to  be  either  supportive  or 
extrinsic. 


AEEUCATION  OF  TIE  RTE  FMORITIZATICH  MATRIX 

After  all  the  weights  and  rates  had  been 
determined  the  next  step  was  to  multiply  the 
weights  by  the  rates.  This  step  integrated 
all  of  the  components  of  the  prioritization 
matrix:  the  ECS  features,  their  relative 
importance  to  the  class  of  systems  (the 
weight) ,  and  the  RTE  elements1  ratings. 

The  last  step  was  to  sum  all  the  products 
in  a  given  raw.  The  result  was  a  prioritized 
list  of  RTE  elements.  The  element  with  the 
highest  total  for  a  row  was  the  most  critical 
element,  and  the  element  with  the  next  highest 
was  the  next  cost  critical,  and  so  on. 
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Figure  1  presents  the  prioritisation 
matrix  for  COKUnymKr  systems. 

The  following  is  the  prioritised  list  of 
R IE  elements. 


1.  Memory  management . 700 

2.  Time  management . 660 

3.  I/O  management  ........  640 

4.  Processor  management . SCO 

5.  Rendezvous  management  .....  SCO 

6.  Deception  management . 540 

7.  Interrupt  management . 500 

8.  Task  Activation . 380 

9.  Task  Termination . 300 

10.  Target  Housekeeping . 380 


11.  Oa-Tcoly  Called  Code  Sequences  .280 

This  list  is  tho  driver  for  prioritising 
groups  of  benchmarks. 


*  vi  ■M4,xiint 

The  last  step  vas  to  top  benchmarks  to 
tho  RTE  elements  they  measure.  The 
oorbination  of  a  prioritised  list  of  RTE 
elements  and  benchmarks  napped  to  each  element 
produced  a  prioritised  list  of  groups  of 
betthmarks.  Tils  is  because  for  each  element 
there  was  a  group  of  benchmarks  that  napped  to 
it.  Thus,  it  vas  the  groups  that  veto 
prioritised  and  not  the  individual  benchmarks. 

Sore  sources  of  benchmarks  that  can  bo 
mapped  to  RTE  elements  and  thus  prioritised 
aro  the  Ada  Ccrpilcr  Evaluation  Capability 
(ACEC)  [Lea  1988)  benchmarks,  tho  Peal-Time 
Performance  Benchmarks  for  Ada  [Cool  1988)  and 
tho  Performance  Issues  Working  Croup  (PIW3) 
berchmarks. 


ECS  FEATURES 
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RATING  SCALE 

INTRINSIC  9 

SUPPORTIVE  5 

EXTRINSIC  1 

Figure  1.  Prioritisation  Matrix  for  CCKD/T/ELINr  Systems. 
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gitreHra.BS»3s&& 

Hie  majority  of  bcrehmarks  available 
either  test  a  specific  element  of  the  RTE  in 
isolation,  or  exercise  several  elements  in 
some  unspecified  ccrblnatico.  What  is  needed 
is  a  single  benchmark  that  tests  elements  of 
an  RtE  while  interacting  in  a  tanner  that  is 
consistent  with  their  interaction  during 
actual  system  operation.  Such  a  benchmark 
would  evaluate  an  Ada  RTE  by  forcing  the  RTE 
to  perform  operations  that  would  mirror  the 
operations  performed  by  the  system  to  bo 
developed.  A  ocepoeite  bendrark  is  such  a 
model  of  the  capabilities  of  a  particular 
class  of  tfystena. 

ftflTOgE.Or.  A.CCi^IIE 

Oho  purpose  of  a  composite  benchmark  is 
to  stress  a  corputer  and  its  RTE  to  check 
their  ability  to  perform  the  capabilities  of  a 
particular  class  of  systems.  A  composite 

benchmark  allows  a  software  developer  to  run 
one  benchmark,  which  will  give  him  a  general 
idoa  of  whether  a  particular  RTE  can  perform 
the  capabilities  of  a  given  class  of  systems. 
A  composite  benchmark  tests  each  capability 
Individually  and,  importantly,  the  interaction 
among  the  capabilities. 

m  or  a  ccmtosite  khomarx 

gsgumaj 

Developing  a  composite  benchmark 

description  for  a  particular  class  of  systems 
is  not  a  simple  task,  but  once  developed  it 
can  be  used  to  aid  in  the  selection  of  an  RTE 
for  any  system  in  the  given  class.  ihe 
following  three  steps  should  be  followed  when 
developing  ccrposite  benchmarks: 

1.  Identify  the  com  ion  capabilities  of  the 
particular  class  of  systems  by  studying 
the  requirements  and  functions  of  the 
systems  within  the  class. 

2.  Define  and  analyze  each  capability.  Iho 
description  should  include  all  functions 
corraon  to  the  systems  in  the  class.  If  a 
particular  function  is  cax.cn  to  several 
of  the  systems  within  the  class,  it 
should  be  included  in  the  description 
because  the  function  nay  be  performed  in 
a  new  system  being  developed. 

3.  Document  the  interactions  and  interfaces 
aneng  the  capabilities  in  a  format  that 
facilitates  computer  program  code 
development.  When  writing  the 
description,  there  needs  to  be  continuous 
interaction  between  the  description 
writer  and  programmer  to  ensure  that  the 
conposite  benchmark  will  be  accurate  and 
understandable.  Ihe  description  writer 
rust  have  an  in-depth  technical  knowledge 
of  the  class  of  systems  being  studied. 


careens  grewra-rai 
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A  preliminary  description  for  a  composite 
benchmark  was  developed  in  this  study  for 
CCKDnyffiOtf  system c.  Ihe  goal  was  to  develop 
the  idea  and  an  approach  for  developing  a 
composite  benchmark.  The  preliminary 
composite  benchmark  models  the  five 
capabilities  of  COKIHT/ELINT  systems: 
intercept,  direction  finding,  emitter 
location,  analysis,  and  reporting.  This 
description  was  given  to  another  cccpany, 
TAJSCD,  for  code  development. 


BS-£ELBaiaLiaaass 

11)0  final  phase  of  this  study  was  to 
determine  how  the  prioritized  benchmarks  and 
the  composite  benchmark  should  be  used  wf.cn 
selecting  an  RTE.  It  was  determined  that 
choosing  an  RTE  is  a  three-step  process.  The 
first  step  is  to  eliminate  all  KTEs  that 
cannot  perform  beyond  a  minimum  required 
threshold  in  each  area  critical  to  system 
performance.  The  second  step  is  to  begin  with 
the  set  of  KTEs  that  satisfy  the  minimum 
threshold  requirements  and  select  the  small 
set  of  RTEs  that  performs  best  in  the  areas 
critical  to  system  performance.  Ihe  final 
step  is  to  ampere  the  costs,  the  vendor 
support  provided,  end  any  other  mitigating 
circumstances  for  the  final  selection  of  an 
RTE  or  ccepiler.  Ihe  first  two  steps  involve 
the  use  of  benchmarks. 

Ihe  composite  benchmark  is  to  be  used  to 
test  the  minima*  threshold  of  RTEs.  Ihis 
moans  the  developer  would  only  have  to  run  one 
benchmark  to  eliminate  RTEs  not  suitable  for 
his  particular  class  of  system.  Ihen  the 
other  benchmarks  would  be  used  to  test  the 
remaining  RTEs  to  soe  which  RTEs  perform  the 
best  in  the  areas  critical  to  system 
performance.  Because  the  RTE  elements  are 
prioritized,  the  critical  areas  and  the 
benchmarks  that  measure  those  areas  are  known. 

At  this  time  the  development  of  the 
composite  benchmark  is  still  in  the 
preliminary  phase.  Until  the  canposite 

benchmark  matures,  only  the  prioritized  list 
of  groups  of  benchmarks  can  be  used  to  test 
RTEs. 


csucmsioH 

Ihe  objective  of  this  study  was  to 
provide  software  developers  with  guidance  in 
the  selection  of  a  occpiler  and  its  RTE  to 
ensure  that  all  the  timing  and  storage 
requirements  of  their  real-time  embedded 
systems  can  be  met.  Because  there  is  no 
"universal  best"  RIS,  the  selection  of  an  RTE 
is  based  on  the  needs  of  a  specific  class  of 
system.  Ihis  means  the  selection  of  an  RTE  is 
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domain  specific,  and  the  use  of  a 
prioritization  matrix  as  described  in  this 
paper  will  allow  for  the  prioritization  of  RTE 
elements  for  a  particular  domain.  The 
prioritized  PTE  elements  are  then  used  to 
prioritize  group*  of  benchmarks. 

Another  domain  specific  way  to  test  KTEs 
is  through  the  use  of  a  cceposita  benchswrk. 
Composite  benchmark*  would  test  each  candidate 
RTE  and  eliminate  those  that  don't  meet  a  set 
of  minimum  requirements.  Unlike  existing 
berehmarks,  a  corposite  benchmark  will  take 
into  account  the  interactions  and  interfaces 
that  go  on  within  a  system. 

Thus,  when  selecting  an  RTE,  the 
corposite  benchmark  would  bo  used  to  test  the 
minimus  threshold  of  KTEs.  Then  the 
prioritized  groups  of  benchmarks  would  be  used 
to  test  the  critical  R TE  elements  to  determine 
which  RTEs  perform  best  in  those  critical 
areas. 

When  developing  this  method  to  prioritize 
RTE  elements,  two  preliminary  steps,  mapping 
system  capabilities  to  Ada  constructs  and 
sapping  Ada  constructs  to  Ada  RTE  elements 
were  done.  These  stops  are  not  discussed  in 
this  paper  so  the  norm  significant  results  of 
the  later  steps  can  be  highlighted.  The 
objective  of  rapping  the  systen  capabilities 
of  COtUKT/EUKT  system  to  Ada  constructs  was 
to  determine  what  Ada  constructs  would  be  used 
in  real- tine  embedded  system.  The  results 
were  that  all  Ada  constructs  would  be  used. 
The  objective  of  rapping  Ada  constructs  to  Ada 
RTE  elements  was  to  determine  which  of  the 
eleven  RTE  elements  were  not  irportant  in 
real-tine  erboddod  system.  During  this  step, 
one  KTE  element,  target  housekeeping,  was 
determined  not  to  be  important.  This  finding 
however  was  contradicted  after  the 
irplencntaticn  of  the  prioritization  matrix. 
As  a  result  the  original  assumption  that 
target  »>ousekooping  was  not  irportant  was 
reversed. 

For  the  process  of  prioritizing  RTE 
elements,  it  is  roccrncndod  that  after  the 
particular  domain  (class  of  systen)  has  been 
selected,  the  first  step  is  the  irplcncntation 
of  u  prioritization  aatrix.  If  the  matrix  is 
applied  to  an  ECS  the  rows  and  columns  of  the 
matrix  are  already  in  place,  if  the  matrix  is 
to  be  applied  to  any  other  type  of  system,  a 
new  sot  of  colum  titles  would  have  to  bo 
developed.  This  is  because  the  features 
cocoon  for  all  ECSs  night  not  be  cccncn  to 
other  systems,  but  there  may  be  sore  overlap. 

There  are  two  future  directions  for  this 
research.  One  is  to  mature  the  preliminary 
description  of  the  cosposite  benchmark  into  an 
in-depth  spec:  fication  and  to  develop  the 
actual  benchmark.  Second  is  to  apply  this 
approach  of  prioritizing  RTE  elements  and 
groups  of  benchmarks  to  another  class  of 
systems. 
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Real-time  Performance  Benchmarks  For  Ada 


Arvind  Gael 


TAMSCO 


Abstract:  I  his  paper  describes  the  Ada 

benchmarking  effort  undertaken  by  the  author  under 
contract  to  Advanced  Software  Technology 
Directorate,  Center  for  Software  Engineering,  US 
Army,  Ft.  Monmouth,  NJ.  Ada  benchmarks  have 
been  developed  to  measure  the  performance  of  Ada 
compilers  meant  for  real-time  embedded  systems. 
Three  kinds  of  benchmarks  have  been  developed: 
first  kind  measures  the  performance  of  Individual 
features  of  Ada  language  important  for  real-time 
systems,  second  kind  of  benchmarks  deal  with 
determining  the  runtime  system  implementation  in 
the  areas  of  tasking,  scheduling,  memory 
management,,  exceptions,  interrupt  handling  etc.,  and 
the  third  kind  involves  programming  algorithms 
found  in  real-time  embedded  systems. 


1.  Introduction 

The  principal  goal  of  Ada  is  to  provide  a  language 
supporting  modem  software  engineering  principles  to 
design  and  develop  real-time  embedded  systems 
software.  A  motivating  factor  in  the  devclopmdit  of 
Ada  as  the .  Department  of  Defense  standard  language 
was  the  high  cost  of  embedded  system  software 
development.  Current  Ada  compiler  implementations  arc 
unable  to  support  these  demands  due  to  several  reasons: 

•  they  are  written  by  software  engineers  with 
experience  in  large-system  (resign, 

•  lack  of  operating  system  knowledge  and  real-time 
issues, 


more  concern  with  passing  the  Ada  Compiler 
Validation  Capability  Test  suite, 


•  implementation  and  size  of  the  Ada  runtime  system 
which  differs  widely  from  one  compiler  to  another. 
The  performance  and  implementation  approach  of 
various  Ada  language  features  and  die  runtime  system 
.  1‘?,.bc  benchmarked  to  assess  an  Ada  compiler's 
suitability  for  a  real-time  embedded  application.  Ada 
benchmarking  is  much  more  complex  from  other 
languages  because  of  the  powerful  and  sophisticated 
runtime  system  that  supports  Ada  features  such  as 
memory  management,  process  scheduling  and  control, 
tasking,  etc.  and  whose  implementation  varies  from  one 
compiler  system  to  another.  A  benchmarking  effort  has 
been  undertaken  by  TAMSCO  to  determine  the 


suitability  of  Ada  compiler  systems  for  embedded 
applications,  Existing  benchmarks  have  been  researched 
and  have  been  modified  as  necessary.  New  benchmarks 
were  added  as  well  as  existing  benchmarks  were 
modified.  Hie  scope  of  this  benchmarking  effort  is  to 
determine 

•  the  runtime  performance  of  Ada  features  on  a  bare 
target  system 

•  the  runtime  system  implementations  of  various 
features  of  a  particular  Ada  compiler  system 

•  the  performance  of  commonly  used  Ada  real-time 
paradigms  (also  referred  to  as  macro  constructs) 

The  benchmarks  developed  have  been  run  on  a  verdix 
compiler  targeted  to  a  Motorola  68020  bare  target.  'Hie 
results  of  running  the  benchmarks  is  stated  in  another 
report  published  by  the  author  ( I ). 

2.  Ada  Benchmarking 

Ada  benchmarking  can  be  approached  in  3  ways: 

•  design  benchmarks  to  measure  execution  speed  of 
individual  features  of  the  language, 

•  design  benchmarks  that  determine  among  various 
other  things  implementation  dependent  attributes  like 
the  scheduling  and  storage  management  algorithms, 

•  design  benchmarks  that  measure  the  performance  of 
commonly  used  real-time  Ada  paradigms. 

2.1  Measure  Performance  Of  Individual  Features 

This  approach  measures  the  execution  speed  of 
individual  features  of  the  language  and  runtime  system 
by  isolating  the  feature  to  be  measured  to  the  finest 
extent  possible.  Such  benchmarks  arc  useful  in 
understanding  the  efficiency  of  a  specific  feature  of  an 
Ada  implementation.  For  example,  a  benchmark  that 
measures  the  time  for  a  simple  rendezvous  can  be  run  on 
two  Ada  compiler  systems.  Based  on  the  results,  an 
application  can  choose  one  compiler  system  over  the 
other.  The  problems  with  such  an  approach  is 
determining  and  isolating  the  features  of  the  language 
and  runtime  system  that  are  important  for  real-time 
embedded  system  applications.  Also,  this  approach 
requires  a  significant  number  of  tests  and  the  numbers 
produced  have  to  be  statistically  evaluated  to  determine 
general  performance. 

22  Determining  Runtime  System  Implementation 
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These  benchmarks  are  concerned  primarily  with 
determining  the  implementation  characteristics  of  an  Ada 
Runtime  System.  The  scheduling  algorithm,  storage 
allocation/dcallocation  algorithm,  priority  of  rendezvous 
between  two  tasks  without  explicit  priorities  arc  some  of 
the  many  implementation  dependent  characteristics  that 
need  to  be  known  to  determine  if  a  compiler  system  is 
suitable  for  a  particular  real-time  embedded  application. 
Some  implementation  dependencies  cannot  be 
benchmarked  and  that  information  has  to  be  obtained 
from  the  compiler  vender  as  well  as  the  documentation 
supplied  by  the  vendor.  The  ARTENVG  document 
“Catalog  of  Ada  Runtime  Implementation  Dependencies" 
(2)  is  a  compiled  list  of  features  that  are  implementation 
dependent.  Tills  document  has  been  consulted 
estensively  in  determining  which  implementation 
dependencies  need  to  be  benchmarked  for  real-time 
embedded  systems. 

2J  Hetil-lhw  Paradigms 

There  are  a  number  of  characteristics  of  real-time 
embedded  systems  that  do  not  correspond  to  a  specific 
Ada  feature,  but  those  characteristics  can  be  constructed 
using  a  combination  of  Ada  features.  This  approach  also 
involves  programming  algorithms  found  in  embedded 
systems.  For  example,  a  situation  in  real-time  systems 
may  be  a  producer  that  monitors  a  sensor  and  produces 
output  asynchronously  and  sends  it  to  a  consumer.  The 
producer  task  cannot  wail  for  a  rendezvous  with  the 
consumer  (who  might  be  doing  something  else)  as  the 
producer  task  might  miss  a  sensor  reading.  To  program 
this  paradigm  in  Ada  requires  three  tasks:  a  producer 
task,  a  buffer  task  that  receives  input  from  the  producer 
task  and  sends  the  input  to  the  consumer  task.  For  real¬ 
time  embedded  systems,  such  paradigms  can  be 
identified  and  programmed  in  Ada.  These  benchmarks 
can  be  run  on  Ada  compiler  implementations  and 
statistics  gathered  on  their  performance. 

3.  Microscopic  Benchmarks 

Microscopic  benchmarks  are  designed  to  measure  the 
performance  of  individual  features  of  the  Ada 
programming  language.  Benchmarks  have  been 
designed  for  all  the  major  Ada  language  features  that  are 
important  for  real-time  embedded  systems.  Since 
optimizing  compilers  generate  different  code  for  the 
same  feature  depending  on  the  context  in  which  the 

feature  occurs,  it  has  been  attempted  to  benchmark  a 
particular  feature  under  different  scenarios.  The  results 
will  demonstrate  the  range  of  performance  associated 
with  a  language  feature. 

After  a  detailed  analysis  of  existing  benchmark  suites,  it 
was  determined  that  the  methodology  developed  by  the 
University  of  Michigan  (1)  is  best  suited  for 
benchmarking  specific  Ada  language  and  runtime 
features  that  are  important  for  real-time  embedded 
systems.  This  suite  addresses  the  issues  that  arc  of 
concern  when  designing  benchmarks  some  of  which  are  : 
isolation  of  features,  accuracy,  and  thwarting  compiler 
optimizations^]. 

3.1  Benchmark  Timing 


For  benchmarks  tltat  measure  ttnvc  values  using  the 
system  function  CLOCK,  the  ideal  design  would  be  to 
determine  the  specific  feature  that  needs  to  be  measured 
and  perform  that  feature  sandwiched  between  calls  to  the 
system  CLOCK.  The  difference  In  time  is  die  execution 
time  for  that  feature.  For  this  measurement  to  be 
accurate,  the  resolution  of  the  CLOCK  should  be 
considerably  less  than  the  time  required  by  the  operation 
to  be  measured.  Generally,  the  system  clock  that  arc 
available  to  a  benchmark  designer  maybe  accurate  to  a 
tenth  of  a  second  and  that  is  inadequate  to  measure 
events  in  the  millisecond  and  microsecond  ranges.  Some 
of  the  problems  that  have  to  be  overcome  when 
accessing  the  internal  CLOCK  function  include: 

1.  Clock  Precision:  In  designing  portable 
benchmarks,  one  can  only  assume  the  presence  of 
the  function  CLOCK  in  the  package  CALENDAR. 
If  the  precision  of  the  CLOCK  function 
tSYSTEM.TICKl  is  not  very  high  it  can  cause 
errors  in  the  liming  measurements.  Generally  the 
execution  time  of  a  Ada  feature  is  much  smaller 
than  SYSTEM.T1CK. 

2.  Clock  Overhead:  Another  problem  is  the 
inconsistent  time  required  for  the  CLOCK 
function.  Sonic  compiler  Implementation  return  an 
aggregate  data  structure  and  this  may  require  the 
calling  of  storage  management  functions  resulting 
in  inconsistent  timing  for  the  CLOCK  function. 

3.  Clock  Jitter:  Clock  readings  arc  subject  to  the 
usual  statistical  variations  associated  with  physical 
measurements  and  can  be  expected  to  show 
random  variations  known  as  jitter. 

To  overcome  these  problems,  a  technique  known  as  the 
dual  loop  technique  (2)  is  used  to  measure  the  execution 
time  for  a  specific  feature.  In  this  technique  an 
operation  is  performed  repetitively,  and  the  aggregate  of 
multiple  executions  is  timed.  By  performing  the 
operation  repetitively,  the  time  duration  of  a  test  is 
increased  and  the  system  clock  can  measure  this  time 
precisely.  In  fact,  this  is  done  twice,  once  in  a  control 
loop  without  the  feature  being  measured,  once  in  a  test 
loop  with  the  feature.  Subtracting  the  execution  time  of 
these  two  loops,  and  dividing  by  the  number  of 
executions  yields  a  calculated  time  for  one  execution  of 
the  feature.  The  dual  loop  technique  solves  a  number  of 
problems  that  have  been  mentioned  above. 

2  Tasking  Benchmarks 

For  Ada  to  fulfill  its  potential  for  embedded  systems,  its 
model  of  concurrency  -  the  tasking  model  *  must  be 
sufficiently  fast  to  meet  the  liming  needs  of  such 
systems.  Concern  over  efficiency  and  semantics  of  Ada 
tasking  could  force  many  organizations  using  Ada  to 
avoid  the  tasking  facilities  entirely,  relying  instead  on  a 
separately  written  executive.  There  are  specific  concerns 
in  the  real-time  application  community  regarding  the 
semantics  of  the  Ada  tasking  model  and  its  potential 
implementation  overhead.  Ada  tasking  model  is 
significantly  different  from  current  real-time  paradigms 
such  as  cyclic  executives.  In  fact  translation  of 
concurrency  paradigms  may  force  creation  of 
intermediary  tasks  with  the  risk  of  compromising  real- 
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lime  performance. 

?2,/  Ttttk  Activitiion-Tcrmirvuien  Some  points  to  note 
about  task  xtivation/terminarion  benchmarks  arc: 

1.  ‘ilte  time  to  elaborate,  activate  ami  terminate  a  task 
is  measured  2s  one  value.  The  individual 
components  of  the  measurements  are  too  quick  to 
measure  with  the  available  CLOCK  resolution. 

2.  Some  implementations  may  implicitly  deallocate 

the  task  storage  space  on  return  from  a  procedure 
or  on  exit  from  a  block  statement  (when  the  task 
object  is  declared  in  a  procedure  or  block 
statement!.  If  task  space  is  implicitly  deallocated, 
the  number  of  iterations  ean  be  increased  to  get 
greater  accuracy  for  task  activation/tennination 
measurement.  If  task  space  is  not  deallocated  on 
return  from  a  procedure  or  block  statement,  then 
the  attribute  STORAGC.SIXli  can  be  changed 
such  that  the  number "  of  iterations  can  be 

increased. 

The  first  set  of  benchmarks  measure  task  activation  and 
termination  time  under  various  scenarios: 

•  These  benchmarks  measure  task  * 

activation/tcrmination  timings  for  task  objects 
declared  in  block  statements,  procedures,  packages, 
other  tasks,  arrays  of  tasks,  and  as  pan  of  a  record. 
ILc  effect  of  existing  active  tasks  on  task 

activation/tcrmination  timings  Is  also  determined. 

•  These  benchmarks  measure  task 

activation/tennination  timings  for  task  objects  created 
via  the  new  allocator.  Timings  arc  measured  for  tasks 
created  in  a  block  staienvcnt,  procedure,  and  array  of 
tasks.  The  effect  of  existing  active  tasks  on  task 
activation/tcrmination  timings  of  (asks  created  via  the 
new  allocator  is  also  detennined.  Since  access  object 
does  not  exist  on  exit  from  the  block  statement,  (he 
timing  measured  includes  both  allocation  and 
deallocation  timings  for  the  task  as  well  as  task 
activation  and  termination  rinses. 

Some  conclusions  that  can  be  drawn  arc: 

1.  'Hie  activation  and  termination  rime  of  tasks  for 
the  various  scenarios  that  are  described  above 
determines  if  a  real-time  programmer  should 
declare  tasks  for  rime-critical  modules  in  packages 
or  in  the  main  procedure,  in  procedures  that  are 
repeatedly  called  by  other  procedures,  or  within 
other  tasks  in  the  system. 

2.  If  an  implementation  docs  not  deallocate  the 
storage  space  occupied  by  a  task  on  exit  from  a 
procedure  then  the  timings  for  task 
activation/tcrmination  using  arrays  and  without 
arrays  should  be  compatible  otherwise  the  timings 
for  task  activation/tcrmination  using  arrays  can  be 
significantly  higher. 

33  Task  Synchronisation 

In  Ada,  tasks  communicate  with  each  other  via  the 
rendezvous  mechanism.  Rendezvous  arc  effectively 
similar  to  procedure  calls,  yet  they  are  much  more 
complex  to  implement,  and  therefore  create  a  tremendous 
amount  of  overhead  for  the  run-time  system.  This 


overhead  affects  the  efficiency  of  the  system  in  both 
sizing  and  timing.  Because  of  the  timing  constraints  in  a 
real-time  embedded  system,  it  Is  essential  that  the 
rendezvous  mechanism  be  as  efficient  as  possible. 

33.1  Simple  f'cndeivGus  The  simple  rendezvous  rime 
gives  a  lower  bound  on  the  rendezvous  time  because  no 
extraneous  units  of  execution  are  competing  for  the 
Cl'U.  This  overhead  is  expected  to  occur  each  time  two 
tasks  are  in  a  rendezvous  and  does  not  include  any 
execution  time  for  the  statements  within  die  accept  body. 
Simple  rendezvous  benchmarks: 

•  Measure  time  for  simple  rendezvous  where  entry 
calls  with  no  parameters  arc  made  to  tasks  declared 
in  the  main  program,  Week  stattesents,  packages, 
procedures,  Benchmarks  arc  als»  designed  to 
determine  if  it  is  advantageous  for  an  application  to 
have  more  tasks  with  less  entries  cr  less  tasks  with 
more  entries. 

•  Benchmarks  have  also  been  designed  to  determine 
the  affect  on  entry  call  rime  as  the  number  of  accept 
alternatives  in  a  select  statement  increases.  For  some 
implementations,  time  for  a  rendezvous  may  also  be 
affected  by  (he  position  of  the  accept  alternative  in 
the  select  statement.  Based  on  these  tests, 
application  designers  can  choose  to  plxe  the  most 
time-critical  xccpi  statements  In  a  certain  manner. 

•  Measure  the  affect  of  guards  (on  xccpt  Statements) 
on  rendezvous  time,  where  the  main  program  calls  an 
entry  In  another  task  (with  no  parameters)  as  the 
number  of  xccpt  alternatives  in  the  select  statement 
increases. 

33.2  Complex  Remtesvous  Complex  rendezvous 
benchmarks: 

•  Measure  the  lime  required  for  a  complex  rendezvous, 
where  a  procedure  in  the  main  program  calls  an  entry 
in  another  task  with  different  type,  number  and  mode 
of  the  parameters.  Rendezvous  time  may  depend  on 
the  size  and  type  of  the  passed  parameters  which 
may  involve  both  the  task  stacks  or  the  allocation  of 
a  separate  area  for  passing  large  structures. 
Increasing  rendezvous  times  for  array  parameters  as 
the  size  of  the  array  increases  implies  that  the 
iniplemcntation  uses  pass  by  copy  instead  of  pass  by 
reference. 

•  Determine  the  affect  on  time  required  for  a  complex 
rendezvous,  where  the  main  program  calls  an  entry  in 
another  task  with  different  type,  number  and  mode  of 
the  parameters  as  (he  number  of  accept  alternatives  in 
the  select  statement  increase.  For  some 
implementations,  time  for  a  rendezvous  may  also  be 
affected  by  the  position  of  the  accept  alternative  in 
the  select  statement.  Also,  the  time  for  rendezvous 
may  increase  as  the  number  of  integer  parameters 
passed  during  the  rendezvous  increases. 

•  Determine  the  cost  of  using  the  terminate  option  in  a 
select  statement.  If  the  overhead  due  to  the  terminate 
option  is  high,  then  this  option  should  not  be  used 
especially  if  the  selective  wait  is  inside  a  loop. 

•  Determine  the  overhead  due  to  conditional  and  timed 
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entry  call*  when  a)  the  rendezvous  Is  completed  b) 
the  rendezvous  I*  not  completed.  This  benchmark 
measures  the  execution  time  overhead  of  the 
conditional  and  limed  entry  calls  when  the 
rendezvous  does  and  does  not  take  place.  This 
overhead  has  to  be  considered  whenever  polling  is 
used  to  establish  synchronization  between  tasks. 

•  Measure  the  affect  on  time  required  for  a  complex 
rendezvous,  where  a  procedure  in  the  main  program 
calls  an  entry  as  the  number  of  activated  tasks  in  the 
system  increases.  Time  for  rendezvous  can  degrade 
with  the  number  of  eligible  tasks  doc  to  the  search 
and  sorting  involved  with  prioritized  dispatching. 

3.4  Scheduling  and  Detoy  Statement 

Task  scheduling  is  an  important  consideration  for  a 
multitasking  application.  Real-time  embedded  systems 
contain  jobs  with  hard  deadlines  for  their  execution. 
Failure  to  meet  a  deadline  reduces  the  value  of  the  job's 
execution  possibly  to  the  extent  of  jeopardizing  the 
system's  mission.  It  is  the  responsibility  of  the  runtime 
system's  scheduling  mechanism  to  guarantee  that  the 
most  important  deadlines  are  met  while  also  meeting  as 
many  or  the  less  important  deadlines  as  possible.  For 
scheduling  tasks  at  a  particular  time,  the  delay  statement 
can  be  used  in  conjunction  with  die  CALENDAR 
package.  The  precision  of  the  timing  depends  on  the 
implementation  of  the  package  CALENDAR  and  on  the 
granularity  of  the  underlying  scheduler.  The  semantics 
for  live  delay  statement,  however,  provides  only  that  the 
delay  specified  Is  a  minimum  amount  of  the  delay  time. 
For  real-time  embedded  systems,  it  is  the  maximum 
delay  not  the  minimum  delay  which  is  of  interest. 
Another  reason  why  Ada  implementation  of  periodic 
tasks  is  not  reliable  is  the  possibility  of  an  interrupt 
between  the  time  the  delay  is  computed  and  the  time  the 
delay  is  requested.  Hence  the  time  at  which  delay 
expires  cannot,  in  general,  be  predicted  in  advance. 

•  Determine  the  minimum  delay  time.  This  benchmark 
determines  the  actual  delay  time  for  a  desired  delay 
time  specified  in  the  delay  statement.  This 
benchmark  starts  by  calculating  the  actual  delay  time 
for  a  minimum  delay  of  DURATION'SMALL.  Hie 
desired  delay  time  is  increased  in  steps  and  the  actual 
delay  time  calculated. 

•  Determine  if  user  tasks  arc  pre-emptive.  Docs  a 
completed  delay  interrupt  the  currently  executing  task 
to  allow  the  scheduler  to  select  the  highest  priority 
tasks. 

3J  Memory  Management 

Ada  is  the  first  high  order  language  intended  for  mission 
critical,  real-time  applications  that  requires  dynamic 
memory  allocation  and  deallocation.  The  amount  of 
storage  required  in  these  circumstances  cannot  be 
determined  by  static  examination  of  a  program  and 
benchmarks  must  be  executed  to  determine  the  efficiency 
of  an  implementation's  storage  utilization. 

•  These  benchmarks  determine  the  time  for  allocating 
storage  known  nt  compile  time.  Time  is  measured  to 
allocate  and  deallocate  a  fixed  amount  of  storage 
upon  entering  a  subprogram  or  a  declare  block.  The 


size  of  the  objects  is  known  at  compilation  time,  but 
space  for  die  objects  is  allocated  on  the  stack  at 
runtime. 

•  Measure  time  for  allocating  variable  amount  of 
Storage  Variable  storage  allocation  Involves 
allocation  of  a  variable  amount  of  storage  when 
entering  a  subprogram  or  declare  block.  In  this  test 
ease,  arrays  of  different  dimensions  bounded  by 
variables  arc  allocated  and  die  size  of  the  objects  is 
not  known  at  compilation  time.  Tests  arc  also 
designed  lu  determine  the  threshold  when  objects  are 
allocated  front  the  heap  rather  than  on  the  stack. 

•  Memory  Allocation  via  the  New  Allocator.  Based 
on  these  timing  measurements,  real-time 
programmers  can  decide  whether  to  use  the  new 
allocator  for  object  elaboration  or  to  declare  the 
object  as  in  fixed  length  ease. 

•  Determine  the  effect  on  time  required  for  dynamic 
memory  allocation  when  memory  is  continuously 
allocated  without  being  freed.  Time  for  dynamic 
allocation  can  depend  on  the  state  of  storage 
management  following  previous  allocations  due  to 
the  need  to  recover  storage  and  efficiently  manage 
the  available  space.  If  memory  is  allocated  in  a  loop 
via  the  new  allocator,  and  the  memory  that  is 
allocated  is  not  freed,  then  the  lime  required  for 
dynamic  memory  allocation  can  be  affected  as  more 
space  is  allocated. 

•  Determine  the  effect  on  time  required  for  dynamic 
nremory  allocation  when  memory  is  continuously 
allocated  without  being  freed  and  also  as  the  number 
of  tasks  in  the  system  increases. 

3.6  Exceptions 

Real-time  embedded  systems  should  be  able  to  handle 
unexpected  errors  at  run-time.  Unexpected  errors  could 
have  disastrous  consequences  if  not  handled  properly. 
Many  real-time  systems  operate  for  long  periods  or  time 
in  stand  alone  mode  and  there  is  a  need  Tor  efficient  and 
extensive  error-handling  for  such  systems.  The  Ada 
exception  handling  mechanism  provides  a  means  by 
which  errors  can  be  detected  and  reported  without 
catastrophic  results.  Two  kinds  of  exceptions  can  be 
raised  when  a  real-time  embedded  system  is  running:  a) 
user-defined  Ada  exceptions  and  b)  predefined  Ada 
exceptions  (like  NUMERIC  ERROR. 

CONSTRAINTERROR,  TASKING_ERROff.  etc.). 
Predefined  exceptions  may  also  be"  raised  because 
particular  conditions  arc  detected  in  the  underlying 
computing  resource.  Exception  Benchmarks: 

•  Measure  the  overhead  associated  with  a  code 
sequence  that  has  an  exception  handler  associated 
with  it,  yet  no  exception  is  raised  during  the 
execution  of  that  code.  Since  exceptions  arc  used  to 
indicate  "exceptional  situations",  exception  handlers 
should  not  be  executed  during  normal  program 
execution. 

•  Measure  exception  response  time  for  a)  user-defined 
exception  and  b)  pre-defined  exceptions 
NUMER!C_ERROR,  CONSTRAINT  ERROR,  and 
TASKING_ERROR  raised  both  fry  the  raise 
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statement  as  well  as  due  to  abnormal  situations  in  the 
application  code.  If  the  exception  handling  times  arc 
significant,  real-time  embedded  system  programmers 
can  check  and  react  to  error  situations  in  their 
program  body  rather  than  using  using  Ada 
exceptions. 

•  Measure  a)  timing  overhead  due  to  exceptions  and  b) 
exception  response  time  when  exception  handled  in 
the  block  statement  when  additional  tasks  arc  present 

in  the-  system.  Real-time  embedded  systems  have 
multiple  tasks  existing  in  the  system,  llte  thiws 
measured  by  these  benchmarks  determine  the  affeet 
of  multiple  existing  tasks  on  exception  response 
times  and  timing  overhead  due  to  exceptions. 

•  Measure  Exception  handling  time  when  exception  is 
raised  and  propagated  one  (two.  three)  lcvcl(s)  below 
where  it  is  handled.  Uscr-dclincd,  and  pre-defined 
(CONSTRAINT  ERROR,  NUMERICJ-RROR,  and 
TASKINGJiRROR)  exceptions  arc  raised  via  the 
raise  statement  as  well  as  abnormal  situations  in 
code.  There  are  three  scenarios:  a)  no  idle  tasks 
exist  in  the  system  when  the  exceptions  arc  raised,  b) 
5  idle  tasks  exist  in  the  system  when  the  exceptions 
arc  raised  and  c)  10  idle  tasks  exist  in  the  system 
when  the  exceptions  are  raised. 

•  Measure  time  to  handle  TASKING  ERROR 
exception  in  the  calling  task.  This  benefimarfc  is 
executed  with  3  scenarios:  none  (5,  10)  idle  tasks 
existing  in  the  system  when  the  exception  is  raised. 
If  task  exception  handling  time  within  a  rendezvous 
is  costly  when  compared  to  exception  handling  time 
in  a  procedure  or  block,  then  serious  consideration 
must  be  given  to  providing  an  exception  handler 
wiihin  the  accept  body  of  the  time-critical  tasks. 

•  Measure  rime  to  propagate  and  handle  exception 
when  a  child  task  has  an  error  duiing  its  elaboration. 
This  benchmark  is  executed  with  3  scenarios:  none 
(5,  10)  idle  tasks  existing  in  the  system  when  the 
exception  is  raised. 

3.7  Chapter  13  Benchmarks 

Ada  defines  some  features  which  allow  a  programmer  to 
specify  the  physical  representation  of  an  entity,  i.c.,  map 
the  abstract  program  entity  to  physical  hardware.  These 
features  arc  implementation-dependent:  an 

implementation  is  not  required  to  support  these  features. 
For  real-time  embedded  systems,  it  is  necessary  to  that 
the  Ada  LRM  Chapter  13  features  be  implemented  and 
made  mandatory  as  the  application  designers  have  to 
deal  with  two  levels,  the  abstract  and  representation 
level.  Some  Chapter  13  benchmarks  include: 

•  These  benchmarks  measure  time  to  perform  standard 
boolean  operations  (XOR,  NOT,  OR,  AND)  and 
assignment  and  comparison  operations  on  records 
and  arrays  of  boolcans.  The  tests  arc  performed  on 
entire  arrays  as  well  as  components  of  arrays.  The 

arrays  are  PACKED  with  the  pragma  'PACK', 
representation  clause  is  used  to  specify  array  size  and 
the  arrays  are  NOT  PACKED  with  the  pragma 
’PACK’. 


•  Measure  the  time  to  do  an  unchecked  conversion  of 
different  types  of  objects  to  other  types. 

•  Measure  the  time  to  store  and  extract  bit  fields  using 
Boolean  and  Integer  record  components.  There  arc  3 
scenarios: 

•  The  lime  to  store  ami  extract  bit  fields  that  arc 
NOT  defined  by  representation  clauses. 

•  The  time  to  store  and  extract  bit  fields  that  are 
defined  by  representation  clauses. 

•  ‘flic  time  to  store  and  extract  bit  fields  that  are 
packed  by  PRAGMA  PACK. 

•  Measure  the  time  to  perform  a  change  of 
representation  from  one  record  representation  to 
another.  Measure  the  time  to  perform  a  change  of 
representation  from  a  packed  array  to  an  unpacked 
array. 

•  Measure  the  time  to  perform  POS,  SUCC,  and  PRED 
operations  on  enumeration  type  with  representation 
clause  specification. 

3.S  Interrupt  iiantlling 

In  real-time  embedded  systems,  efficient  handling  of 
interrupts  is  very  important.  Interrupts  arc  asynchronous 
events.  In  a  real-time  embedded  system,  interrupts  are 
critical  to  the  ability  of  the  system  to  respond  to  real¬ 
time  events  and  perform  its  required  functions  and  it  is 
essentia)  that  the  system  responds  to  the  interrupt  in 
some  fixed  amount  of  lime.  Benchmarks  for  interrupt 
handling  include: 

•  Measure  Interrupt  Response  Time.  Techniques  for 
measuring  interrupt  response  time  are  very  difficult 
as  hardware  extern*!  to  the  CPU  must  be  involved  in 
order  to  generate  Interrupts.  This  measure  is  totally 
dependent  on  the  hardware  involved,  although  souk 
general  criteria  for  measuring  the  interrupt  response 
time  is  discussed  in  this  report.  External 
instrumentation  (c.g.,  electronic  equipments,  real-time 
timers  etc.)  is  required  to  accurately  capture  the  lime 
of  interrupt  occurrence. 

3.9  Clock  Function  anti  TYPE  Duration 

For  real-time  embedded  systems,  the  CLOCK  function  in 
the  package  CALENDAR  is  going  to  be  used 
extensively.  The  implementation  of  the  system  clock  is 
an  important  factor  in  the  overall  capabilities  of  the 
systeni.  The  CLOCK  function  reads  the  underlying 
timer  provided  by  the  system  and  returns  the  value 
associated  with  the  timer.  If  the  time  taken  to  execute 
the  CLOCK  function  is  less  than  the  time  resolution, 
successive  evaluation*:  of  CLOCK  will  return  the  same 
value.  Most  computer  architectures  have  two  kinds  of 
hardware  for  timing.  The  counter  timer  chip  used  to 
drive  the  system  clock  defines  the  minimum  granularity 
of  time  available  to  the  system.  The  second  level  of 
granularity  is  the  basic  clock  period  which  can  be  found 
in  the  Ada  package  SYSTEM  (SYSTEM.TICK). 
Typically,  some  reasonable  value  is  chosen  for  the  size 
of  the  CLOCK  period,  and  an  interrupt  is  generated  at 
this  rate. 
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Tltc  Ada  type  DURATION  i$  not  required  to  have  the 
same  resolution  as  the  clock  period.  It  is  required  by  the 
Ada  LRM  to  be  at  most  20  milliseconds  and  that  if  be 
no  more  than  50  microseconds.  A  real-time  embedded 
system  has  tinting  constraints  that  require  response 
within  a  predetermined  time  interval.  Tltc  dock  period 
or  resolution  of  type  DURATION  must  support  these 
requirements.  Benchmarks  include: 

•  Measure  CLOCK  function  overhead.  If  the  overhead 
associated  with  executing  the  CLOCK  function  is 
high,  then  real-time  embedded  systems  will  be 
hesitant  to  use  the  CLOCK  function.  Also,  as 
discussed  previously,  the  CLOCK  overhead  docs  add 
to  the  time  required  to  make  a  benchmark 
measurement.  But  the  dual  loop  benchmarking 
strategy  can  negate  this  effect  by  subtracting  the 
control  loop  from  the  test  loop. 

•  Measure  CLOCK  resolution.  If  the  resolution  lime 
of  the  CLOCK  function  is  not  high,  then  for  real¬ 
time  applications  a  higher  resolution  clock  is  needed. 

3.10  Numeric  Computation 

An  embedded  system  must  lie  able  to  represent  real- 
world  entities  and  quantities  to  perform  related 
manipulations  and  computations.  There  should  be 
support  for  numerical  computation,  units  of  measure 
(including  time),  and  calculations  and  formulae  from 
physics,  chemistry  etc.  Benchmarks  include: 

•  Measure  the  overhead  associated  with  a  call  to  and 
return  from  the  "+“  and  functions  provided  in  the 
package  CALENDAR.  For  real-time  embedded 
systems,  it  is  necessary  to  dynamically  compute 
values  of  type  TIME  and  DURATION.  If  the 
overhead  involved  in  this  computation  is  significant, 
the  actual  delay  experienced  will  be  longer  than 
anticipated  which  could  be  critical  for  real-time 
systems. 

•  Determine  time  required  for  float  matrix 
multiplication  and  addition,  factorial  and  squareroot 
calculations. 

3.1 1  Subprogram  Overhead 

In  Ada,  subprograms  rank  high  among  program  units 
from  a  system  structure  point  of  view.  Systems  designed 
and  implemented  in  Ada  appear  as  a  collection  of 
packages  and  subprogram  units,  each  of  which  may  have 
multiple  procedures.  For  real-time  programmers  to  use 
good  programming  techniques  and  structured  system 
design  methodologies,  it  is  important  that  subprogram 
call  mechanism  be  as  efficient  as  possible. 

If  the  subprogram  overhead  is  high,  then  the  compiler 
can  generate  INLINE  expansion  at  the  cost  of  increasing 
the  size  of  the  object  code.  However,  if  calls  to  that 
subprogram  arc  made  from  a  lot  of  places,  then  the 
pragma  INLINE  defeats  the  purpose  due  to  increase  in 
size  of  object  code.  In  embedded  systems  where 
memory  is  at  a  premium  using  pragma  INLINE  may  not 
be  a  practical  solution.  Also,  a  compiler  implementation 
may  not  support  pragma  INLINE.  If  subprogram 
overhead  is  high,  programmers  may  be  forced  to  use 
assembly  language  for  time  critical  regions. 


From  our  own  experience  as  well  as  after  analyzing 
existing  benchmarks,  subprogram  overhead  has  to  be 
measured  for  inter-  and  intra-packages  as  well  as  generic 
and  non-generic  instantiations  of  code.  Procedure  Call 
Latency  is  the  elapsed  time  between  the  moment  of  the 
event  to  the  start  of  the  statement  execution  following 
the  event.  In  all  the  benchmarks,  simple  and  composite 
parameters  arc  passed  with  nodes  in,  out,  and  in  out. 
lire  following  eases  arc  considered: 

•  Intrn  package  reference:  both  caller  and  called 
subprogram  arc  part  of  the  same  package.  Procedure 
call  overhead  is  also  measured  for  intra  package  calls 
with  pragma  INLINE.  If  the  timing  for  subprogram 
overhead  for  intra-package  calls  (without  pragma 

INLINE  )is  nearly  zero,  then  it  is  possible  that  the 
compiler  is  INLINing  procedure  calls. 

•  Inter  Package  Reference:  'llte  motivation  for  inter- 
package  tests  is  to  compare  the  subprogram  call 
overhead  and  procedure  call  latency  time  between 
intra-  and  inter-package  calls. 

•  Instantiations  of  Generic  Code:  In  the  tests  for  inter- 
and  intra-package  calls,  the  subprograms  arc  part  of 
generic  packages  that  arc  instantiated. 

3.12  Pragnuis 

'Hie  main  purpose  of  pragmas  is  to  select  particular 
runtime  features  of  the  language  or  to  override  the 
compiler’s  default.  There  are  certain  predefined  pragmas 
which  are  expected  to  have  an  impact  on  the  execution 
time  and  space  of  a  program.  These  include: 
CONTROLLED.  INLINE.  OPTIMIZE.  PACK, 
PRIORITY,  SHARED,  anti  SUPPRESS. 

•  The  benchmarks  for  pragma  SUPPRESS  determine 
the  improvement  in  execution  time  when  pragmas 
SUPPRESS  is  used.  These  are  test  problems  which 
contain  the  same  source  text  where  the  only 
difference  between  the  problems  is  the  presence  (or 
absence)  of  pragmas.  Pragma  SUPPRESS  causes  the 
compiler  to  omit  the  corresponding  exception 
checking  (RANGE_CHECK,  STORAGE_C!  IECK 
etc.)  that  occurs  at  runtime. 

•  Determine  if  pragma  CONTROLLED  has  any  affect 
for  a  access  type  object. 

•  Benchmarks  for  pragma  INLINE  and  PACK  are 
covered  before. 

3.13  InputlOulput 

Embedded  systems  depend  heavily  on  real-time  input 
and  output.  An  Ada  embedded  system  must  have 
potential  access  to  I/O  ports,  to  control,  status  and  data 
registers  (for  a  memory  mapped  scheme),  to  direct 
memory  access  controllers,  and  to  a  mechanism  for 
enabling  and  disabling  interrupts.  An  excellent 
discussion  of  I/O  is  provided  in  the  paper  by  Weiderman 
[9).  Real-time  I/O  is  subject  to  strict  timing 
requirements  and  can  be  either  synchronous  or 
asynchronous.  To  handle  I/O  for  a  specialized  device,  a 
special  interface  is  needed.  This  interface  provides  the 
attributes  found  in  device  drivers  and  interrupt  handlers. 
I/O  benchmarks: 
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•  Determine  if  true  asynchronous  I/O  is  implemented. 

•  These  benchmarks  deal  with  TEXTJO.  The  tests 
are  designed  to  open  data  file  for  reading  and 
copying  the  data  to  another  file.  Time  is  measured  to 
achieve  the  above  for  each  type  of  10  mentioned 
above,  create  an  output  file  and  then  copy  the  fixed 
type  values  from  the  input  file  to  the  output  file. 

4.  Runtime  Implementation  Denchnutrks 

The  Ada  Language  Reference  Manual  (LRM)  has  a  lot 
of  implementation  dependent  features  that  are  of  concent 
to  real-time  programmers.  A  list  of  the  implementation 
dependent  features  is  compiled  in  a  document  published 
by  the  Ada  Runtime  Environment  Working  Group  {5}. 
The  large  variance  in  implementation  options  for  a 
feature  affect  application  program  behavior  and 
efficiency,  litis  is  a  clear  signal  that  simply  adopting  the 
language  as  defined  in  the  LRM  is  not  enough  for  real¬ 
time  embedded  systems.  The  implementation  approach 
of  various  Ada  language  features  and  the  runtime  system 
has  to  be  benchmarked  to  assess  an  Ada  compiler's 
suitability  for  a  real-time  embedded  application. 

4.1  Tasking 

Tasking  runtime  implementation  dependencies: 

•  Determine  if  task  space  is  deallocated  on  return  from 
a  procedure  (when  a  task  that  has  been  allocated  via 
the  new  operator  in  that  procedure  terminates).  In 
real-time  embedded  systems,  where  space  is  at  a 
premium,  it  is  necessary  that  task  space  be 
deallocated  when  that  task  terminates. 

-  Determine  if  tasks  that  are  allocated  dynamically  by 
the  execution  of  a  allocator  do  not  have  their  space 
reclaimed  upon  termination  when  access  type  is 
declared  in  a  library  unit  or  outermost  scope.  It 
might  be  impossible  for  the  runtime  system  to 
deallocate  the  task  storage  space  after  termination. 
This  is  because  the  access  value  might  have  been 
copied  and  an  object  might  still  be  referencing  the 
terminated  tasks  task  control  block. 

•  Determine  the  order  of  elaboration  when  several 
tasks  arc  activated  in  parallel.  When  several  tasks 
are  activated  in  parallel,  the  order  of  their  elaboration 
may  affect  program  execution. 

•  Can  a  task,  following  its  activation  but  prior  to  the 
completion  of  activation  of  tasks  declared  in  the 
same  declarative  part,  continue  execution.  The 
activation  of  tasks  proceeds  in  parallel.  Correct 
execution  of  a  program  may  depend  on  a  task 
continuing  execution  after  its  activation  is  completed 
but  before  all  other  tasks  activated  in  parallel  have 
completed  their  respective  activations. 

•  If  the  allocation  of  a  task  object  raises  the  exception 
STORAGE  ERROR,  when  is  the  exception  raised? 
The  LRM  (Toes  not  define  when  STORAGE_ERROR 
must  be  raised  should  a  task  object  exceed  the 
storage  allocation  of  its  creator  or  master.  The 
exception  must  be  no  later  than  task  activation: 
however  an  implementation  may  choose  to  raise  it 
earlier. 


-  What  happens  to  tasks  declared  in  a  library  package 
when  the  main  program  terminates?  For  some  real¬ 
time  embedded  applications,  it  is  desirable  that  such 
tasks  do  not  terminate.  System  designers  need  to 
know  this  information. 

•  Determine  order  of  evaluation  of  tasks  named  in  an 
abort  statement.  Abort  statement  provides  a 
convenient  way  to  terminate  a  task  hierarchy.  When 
a  task  Tl  aborts  a  task  T2,  the  result 
TTCOMPLETED  is  true  when  evaluated  by  Tl. 
Other  tasks  may  net  immediately  detect  that 
T2’C0MPLETED  is  true.  In  real-time  embedded 
systems,  tasks  may  have  to  be  aborted  in  a  certain 
sequence.  The  semantics  of  the  abort  statement  do 
not  guarantee  immediate  completion  of  the  named 
task.  Completion  must  happen  no  later  than  when  the 
task  reaches  a  synchronization  point. 

•  Some  other  runtime  implementation  dependencies 
that  concern  the  abort  statement  and  cannot  be 
benchmarked  are: 

•  When  docs  a  task  that  becomes  aborted  become 
completed? 

•  What  arc  the  results  if  a  task  is  aborted  while 
updating  a  variable  ? 

•  Determine  algorithm  used  when  choosing  among 
branches  of  a  selective  wait  statement. 

•  Determine  algorithm  used  when  choosing  ameng 
branches  of  a  selective  wait  statement. 

•  Determine  that  on  queued  entry  calls  if  a  compiler 
uses  the  FIFO  method  of  accepting  the  entry  calls 
that  arrived  first,  irrespective  of  the  priorities  of  the 

entry  calls  queued  up. 

•  Determine  the  order  of  evaluation  for  guard 
conditions  in  a  selective  wait. 

•  Determine  method  used  to  select  from  delay 
alternatives  of  the  same  delay  in  a  selective  wait. 

•  The  following  information  needs  to  be  supplied  by 
the  compiler  vendors  about  task  priority. 

1.  Determine  priority  of  tasks  (and  of  the  main 
program)  that  have  no  defined  priority. 

2.  Determine  priority  of  a  rendezvous  between 
two  tasks  without  explicit  priorities. 

3.  Determine  if  a  low  priority  task  activation 
could  result  in  a  very  long  suspension  of  a 
high  priority  task. 

•  Docs  delay  0.0  simply  return  control  to  the  calling 
task  or  causes  scheduling  of  another  task. 

4.2  Memory  Management 

•  Determine  STORAGE_ERROR  threshold.  This  tests 
arc  basically  concerned  with  determining  at  which 
point  exception  STORAGE_ERROR  is  raised.  If 
memory  is  allocated  in  a  loop  via  the  new  allocator, 
and  the  access  variable  that  is  pointing  to  the 
allocated  memory  remains  throughout  the  run,  then 
STORAGE_ERROR  will  be  raised  at  some  point.  A 
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real-time  embedded  systems  programmer  needs  to 
know  the  amount  of  memory  that  can  be  dynamically 
allocated  without  raising  STORAGEJ-RROR. 

•  Determine  if  Garbage  collection  is  performed  on  the 
fly.  Determine  if  Garbage  collection  is  performed  on 
scope  exit. 

•  Determine  if  Unchecked  Deallocation  ,s 
implemented. 

•13  Interrupt  limiting 

The  following  information  about  intcmipt  handling  is 
needed  by  the  software  designers.  This  information  has 
to  be  obtained  from  the  compiler  vendor. 

•  Determine  if  an  intcmipt  entry-  call  is  implemented  as 
a  normal  Ada  entry  call,  a  timed  entry  call,  or  a 
conditional  entry  call.  Implementation  restrictions  on 
these  intcmipt  entries.  Can  they  called  from  the 
application  code?  Can  they  have  parameters  ? 

•  Determine  if  an  interrupt  is  lost  when  an  interrupt  is 
being  handled  and  another  interrupt  is  received  from 
the  same  device. 

•  Determine  the  restrictions  imposed  by  an 
implementation  for  selection  of  the  terminate 
alternative  that  may  appear  in  the  same  select 
statement  with  an  accept  alternate  for  an  interrupt 
entry.  Selecting  the  terminate  alternative  may 
complete  the  task  which  contains  the  only  accept 
statements  which  can  handle  the  interrupt  entry  calls, 
leaving  the  hardware  unscrviccd. 

•  Determine  if  an  interrupt  entry  call  invokes  any 
scheduling  decisions. 

An  interrupt  need  not  invoke  any  scheduling  actions. 

•  Determine  if  accept  statement  executes  at  the  priority 
of  the  hardware  interrupt,  and  if  priority  is  reduced 
once  a  synchronization  point  is  reached  following  the 
completion  of  accept  statement. 

•  Determine  if  interrupt  entries  can  be  called  from 
application  code. 

5.  Real-Time  Paradigms 

The  designers  ot  real-time  embedded  systems  have  to 
live  with  the  problems  of  Ada  until  a  solution  is  found 
(maybe  by  revising  the  language).  Users,  system 
programmers,  and  academicians  have  found  a  number  of 
useful  paradigms  for  building  concurrency.  Real-time 
systems  will  be  designed  as  a  set  of  cooperating 
concurrent  processes  (Ada  tasks)  using  the  Ada  tasking 
model.  Translation  of  concurrency  paradigms  may  force 
the  creation  of  intermediary  tasks  with  the  risk  of 
compromising  real-time  performance.  This  includes 
intermediary  tasks,  monitor/proccss  structure, 
asynchronous  message  passing,  interrupt  procedures,  and 
event  signaling.  These  paradigms  can  be  coded  in  Ada 
and  benchmarked.  Also,  a  compiler  implementation  may 
recognize  these  paradigms  and  perform  optimizations  to 
implement  that  paradigm  much  more  efficiently.  Some 
paradigms  that  have  been  benchmarked  include: 


•  Intermediary  Tasks:  Many  real-time  implementations 
require  buffered  and  unsynchronized  communication 
between  tasks.  Rendezvous  is  the  mechanism  used 
in  Ada  for  task  communication.  Due  to  the 
rcnde',vous  being  a  synchronous  and  unbuffered 
rocs.  c  passing  operation,  intermediaty  tasks  arc 
needed  to  uncouple  the  task  interaction  to  allow  tasks 
more  independence  and  increase  the  amount  of 
concurrency.  Various  combinations  of  intermediary 
tasks  arc  used  in  different  task  paradigms  to  create 
varying  degrees  of  asynchronism  between  a  producer 
and  consumer.  Intermediary  tasks  introduce  a  lot 
more  rendezvous  in  a  real-time  system  than  if  a 
producer  and  consumer  were  directly  communicating 
with  each  other.  The  use  of  intermediaries  also  adds 
to  the  cost  of  executing  a  real-time  design  in  Ada. 
The  benchmarks  in  this  section  evaluate  the  cost  of 
introducing  intermediary  tasks  for  various  real-time 
tasking  paradigms.  The  goal  of  these  benchmarks  is 
to  give  real-time  programmers  a  feel  for  the  cost  of 
using  such  paradigms  in  a  real-time  embedded 
application  and  to  avoid  using  such  paradigms  if  the 
cost  is  unacceptable  for  a  real-time  system.  Some  of 
the  scenarios  that  have  been  benchmarked  include: 
Producer-Consumer,  Buffer  Task,  Use  of  a  Buffer 
and  Transporter,  use  of  a  Buffer  and  Two 
Transporters,  use  of  a  Relay  etc. 

•  Asynchronous  Exceptions:  Quick  restarts  of  tasks 
arc  required  in  a  number  of  real-time  embedded 
systems.  Ada  model  of  concurrency  docs  not 
provide  an  abstraction  where  a  task  may  be 
asynchronously  notified  that  it  must  change  its 
current  execution  state.  One  way  to  implement 
asynchronous  change  in  control  is  to  abort  the  task 
and  then  replace  it  with  a  new  one.  Aborting  a  task 
may  not  be  appropriate  for  an  application  because  an 
abort  can  take  a  long  time  to  complete  or  because  the 
asynchronous  change  of  control  needed  is  something 
other  than  termination.  Abort  and  task  initialization 
arc  expensive  operations  and  a  abort  could  take  a 
long  elapsed  time  to  complete. 

•  Selection  of  Highest  Priority  Client  during  an  Entry 
Call:  The  LRM  states  that  in  a  select  statement  if 
more  than  one  accept  is  open  and  ready  for  a 
rendezvous,  then  any  one  accept  can  be  chosen  and 
the  choice  is  left  to  the  compiler  implementor.  In 
real-time  embedded  systems,  it  may  be  necessary  to 
choose  the  highest  priority  waiting  client. 

This  benchmark  implements  a  a  generic  package  that 
orders  client  requests  so  that  they  arc  processed  by 
the  server  in  a  priority  order.  This  package  logically 
exists  as  an  intermediary  between  the  clients  and  the 
server.  The  overhead  to  this  solution  is  three 
additional  rendezvous  for  each  prioritized 
rendezvous. 

•  Monitor/Proccss  Structure:  A  monitor  is  commonly 
used  for  controlling  a  systems  resource.  Such"  a  task 
performs  a  watchdog  function  and  would  be 
classified  as  an  actor  task  (Actor  tasks  are  active  in 
nature  and  make  use  of  other  tasks  to  complete  their 
function).  Semaphores  are  an  effective  low-level 
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synchronizing  primitive.  However,  the  use  of 
semaphores  in  an  complex  application  can  result  in 
disaster  if  an  occurrence  of  a  semaphore  operation  is 
omitted  somewhere  in  the  system  or  if  the  use  or  a 
semaphore  is  erroneous.  A  monitor  replaces  the 
need  to  perform  operations  on  semaphores.  Entry  to 
a  monitor  by  one  process  excludes  entry  by  any  other 
process.  A  monitor  thereby  ensures  that  if  it  has 
exclusive  access  to  a  resource,  then  a  monitor  s  user 
has  exclusive  access  to  that  resource.  In  this 
program,  a  monitor  is  developed  in  Ada.  Hie 
problem  is  having  a  pool  of  data  common  to  a  group 
of  processes.  'Hie  data  in  the  pool  may  be  set  by  one 
or  more  processes  or  wed  by  one  or  more  processes. 
Any  number  of  processes  are  allowed  to  read  the 
pool  simultaneously,  but  no  reads  arc  permitted 
during  a.  write  operation.  'Hie  monitor  developed  is 
used  to  control  the  reading  and  writing  of  data  to  the 
pool. 

•  Mailbox:  In  message  passing,  a  question  that  arises 
is  where  messages  arc  to  be  deposited.  A  common 
paradigm  involves  "mailboxes"  which  arc  global 
variables  uixlatcd  by  processes  to  provide 
asynchronous  communication.  These  arc  specially 
suitable  for  such  situations  as  the  produccr/consumcr 
scenario  in  which  a  producer  produces  some  output 
which  is  consumed  by  a  consumer  process.  The 
mailbox  implementation  ol  this  involves  a  global 
mailbox  visible  to  boih  these  processes,  and  a  send 
operation  by  the  producer  into  this  mailbox.  The 
consumer  then  performs  a  receive  opcratlOw  on  the 
mailbox  to  retrieve  the  data. 

6.  Conclusions 

Benchmarking  Ada  implementations  to  determine  their 
suitability  for  real-time  embedded  systems  is  an 
extremely  complex  task.  This  job  is  made  even  more 
difficult  due  to  differing  requirements  or  various  real* 
lime  applications.  In  the  near  future,  the  authors  plan  to 
develop  composite  benchmarks  10  model  some  real-time 
systems  used  in  the  US  Army. 
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ABSTRACT 

The  Ada  programming  language  has  been 
available  10  software  developers  for  several  years, 
yet  its  acceptance  into  the  real-time  embedded 
applications  for  which  it  was  intended  has  been  less 
than  universal.  This  project  was  designed  to  study 
the  capabilities  of  Ada  in  the  most  difficult  real-time 
applications  which  have  traditionally  been  done  in 
low  level  languages.  A  compile/  with  essentially  all 
of  the  optional  features  of  Ada  and  very  good  tasking 
performance  was  selected  to  assess  the  state  of  the 
art  in  Ada  compilation  systems.  The  project  is 
described  as  well  as  specific  real-time  requirements 
that  were  imposed  on  its  implementation.  Details  of 
the  problems  encountered  and  the  findings  of  the 
development  team  arc  provided  to  guide  others  who 
will  be  using  Ada  for  similar  applications  in  the  near 
future. 


BACKGROUND 

There  is  an  ongoing  program  at  the  Center  for 
Software  Engineering  at  CECOM  to  explore  Ada 
real-timc/runtimc  technology  for  the  purpose  of 
providing  guidance  to  the  developers  of  Army 
embedded  real-time  Ada  systems.  A  large  number 
of  research  tasks  on  various  real-time  topics  have 
been  completed  and  others  arc  in  progress.  Work  in 
this  program  area  has  been  supported  by  CECOM, 
STARS,  and  AJPO. 

The  program  is  based  on  recognized  problems 
and  the  consensus  of  experts  in  this  area.  It  began 
with  an  extensive  study  to  identify  the  root  problems 
causing  difficulties  in  the  development  of  real-time 
systems  written  in  Ada.  Program  managers  and 
developers  were  interviewed  and  a  list  of  problems 
was  defined,  analyzed,  and  compiled  into  a 
database.  From  this  identified  set  of  problems, 
studies  were  initiated  on  various  topics.  These 
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included  tasks  that  Investigated  guidelines  to  Select 
and  use  an  Ada  Runtime  Environment  (RTE).  an 
approach  to  tailor  and  configure  a  RTE,  benchmark 
evaluation  and  development  for  performance  testing, 
reuse  handbook  extension  for  real-time,  a  real-time 
methodology  framework,  and  transportability 
guidelines. 

After  establishing  this  set  of  problems,  the 
next  step  was  to  pick  a  prominent  difficulty  and  show 
how  to  solve  it.  A  large  percentage  of  those 
interviewed  pointed  to  the  lack  of  performance 
provided  by  an  Ada  RTE  compared  to  what  is  needed 
for  real-time  embedded  systems.  In  particular,  Ada 
tasking  facilities  have  performed  poorly  in 
comparison  with  alternative  approaches.  It  should  be 
noted  that  performance  is  always  an  issue  in  real¬ 
time  systems,  even  when  programmed  in  assembly 
language,  but  the  problem  is  made  more  pronounced 
when  a  high  order  language  such  as  Ada  is  used. 


APPROACH 

An  approach  to  solving  this  performance 
problem  was  defined  through  the  demonstration 
project  which  is  the  subject  of  this  paper.  It  proposed 
to  develop  a  real-time  application  with  a  single  Ada 
program  containing  multiple  tasks  and  measure  its 
performance.  Then  the  program  would  be  distributed 
as  appropriate  onto  multiple  CPUs  to  obtain  the 
desired  performance  that  couldn't  be  obtained  with  a 
single  CPU.  This  approach  recognizes  that  to  regain 
die  performance  lost  through  the  use  of  a  high  order 
language,  users  must  take  full  advantage  of  the 
language  which  allows  complexity  to  be  managed 
more  easily.  Additional  complexity  can  take  the  fomi 
of  a  sophisticated  algorithm  which  if  more  efficient  or 
by  adding  additional  processing  elements  to  increase 
throughput.  In  order  to  improve  the  performance  of 
systems  developed  with  Ada,  developers  should 
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ukc  advantage  of  parallel  structures  within  the 
language  which  facilitate  the  use  of  additional 
processors  to  increase  system  performance.  Having 
the  ability  to  add  processors  to  achieve  system 
performance  requirements  allows  for  substantial  risk 
reduction. 

In  addition  to  solving  an  identified  problem, 
the  overall  goals  of  the  project  were  many.  The 
dil  a'.tics  in  real-time  Ada  programming  were 
addressed  from  an  Ada  technology  perspective.  The 
demonstration  wanted  to  show  how  to  work  through 
a  problem  and  not  work  around  it  as  may  be 
necessary  in  the  "heat  of  battle"  associated  with 
hardware/softwarc  integration.  The  project  wanted 
to  show  there  can  be  near-term  solutions  to  critical 
problems  while  continuing  research  on  long-term 
solutions.  The  results  are  intended  to  provide 
accurate  details  on  some  of  the  "perceived"  problems 
with  Ada  for  real-time  to  determine  if  they  arc  "real" 
problems  or  rather  problems  created,  for  example, 
because  of  the  preconceived  mindset  of  the  developer 
or  other  non-Ada  causes,  it  was  also  designed  to 
study  and  document  difficulties  in  distributing  tasks 
within  Ada  programs  onto  a  multiple  CPU  RTO.  It 
indicates  what  is  achievable  using  Ada  and  how 
performance  can  be  improved  by  judicious  use  of 
language  features.  Finally,  the  project  attempts  to 
show  that  it  can  be  practical  to  use  distributed 
systems  effectively  within  the  Ada  model  of 
concurrency  and  that  the  difficulty  of  adding  additional 
processors  can  be  minimized.  The  work  done  on  this 
project  is  expected  to  be  made  available  to  other 
researchers,  developers,  compiler  writers,  and 
members  of  the  Ada  real-time  community  to  aid  in 
understanding  and  resolving  the  real-time  Ada 
issues. 

Two  separate  but  related  topics  are  covered 
by  this  project:  a  rcal-tinve  application  developed  to 
be  run  on  a  uniprocessor,  and  the  distribution  of  Ada 
programs  for  loosely  coupled  multiprocessors.  The 
software  was  developed  to  be  independent  of  the 
target  architecture.  Therefore  it  was  developed  with 
the  intention  of  running  on  a  single  CPU  essentially 
divorced  from  the  underlying  implementation 
architecture.  The  distribution  aspects  were 
intentionally  deferred  until  after  the  detailed  design 
to  prevent  the  characteristics  of  the  distribution 
mechanism  from  influencing  the  design.  The  intention 
was  to  make  the  distribution  process  as  simple  ns 
possible.  Current  approaches  require  using  non-Ada 
tasking  primitives.  Using  non-Ada  tasking 
primitives  means  modifying  the  source  substantially 
when  distribution  occurs  ard  understanding  two 
distinct  tasking  models.  This  project  utilized  a 


commercially  available  Ada  compiler  and  supported 
the  Ada  semantics  by  extending  the  runtime  system. 
The  vendor  supplied  runtime  code  was  not  modified 
except  to  customize  interface  routines  for  a  specific 
hardware  (inter  and  interrupt  controller.  The  unit  of 
distribution  supported  was  the  Ada  task.  The  issue 
of  shared  memory  has  frequently  been  addressed  by 
totally  restricting  its  use.  Although  distributed 
shared  variables  weren't  needed  for  this  initial 
prototype,  an  analysis  was  done  on  what  would  be 
required  to  support  such  variables  because  they 
would  give  greater  generality  to  what  can  reasonably 
be  distributed.  Full  Ada  semantics  including  the  Ada 
rendezvous  were  preserved  across  the  distributed 
system  so  that  no  source  code  changes  were 
necessary  to  alter  the  allocation  of  tasks  to 
processors.  Tills  allocation  was  done  using  a  simple 
disiribuiion  table  that  specified  the  object  names,  the 
processor  ID,  and  relevant  characteristics. 


PROJECT  DESCRIPTION 

The  project  involves  (he  development  of  a 
typical  weapon  system  application  with  severe 
performance  requirements.  The  application  is 
synthetic,  but  resembles  many  similar  weapon 
systems  in  DoD  applications  in  terms  of  scheduling 
and  real-time  requirements.  It  includes  target 
tracking,  weapon  guidance,  graphics  and  user 
interface  functions  all  integrated  into  a  complex 
application.  In  some  eases,  simplifications  were 
adopted  because  they  did  not  alter  the  nature  of  the 
application  significantly  and  to  reduce  some  of  the 
detail  that  was  felt  to  be  redundant  for  demonstration 
of  capability.  The  scenario  chosen  describes  the 
problem  and  solution  in  terms  recognizable  to  many 
users  and  developers  of  real-time  applications 
without  being  tied  to  any  one  particular  system. 

The  hypothetical  weapons  application  is 
called  the  Border  Defense  System  (BDS).  It  is 
designed  to  provide  short  to  medium  range  protection 
against  a  massive  armored  attack.  The  BDS  tracks 
ground  targets  and  attempts  to  destroy  these  targets 
with  guided  rockets.  In  addition,  a  simulator  was 
developed  that  provided  target  and  rocket  motion. 
The  BDS  receives  target  position  infomtation  from  a 
surveillance  system  (simulator),  generates  a  real¬ 
time  graphics  display  for  an  operator,  launches 
rockets  to  intercept  targets,  provides  real-time 
rocket  guidance  data,  updates  the  color  graphics 
display  to  indicate  the  rockets'  flight  progress  in  real¬ 
time,  and  provides  post  attack  assessment 
information  and  the  number  of  active  targets  and 
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rockets  to  the  BDS  operator. 

The  performance  require  me  ms  of  the  BDS 
specify  a  one  hundred  percent  hit  rate  while  operating 
in  the  absence  of  effective  countermeasure  and  with 
the  conditions  specified  in  the  Parameter  Data  Base 
(PDB).  The  PDB  enumerates  target  and  rocket 
parameter  ranges  for  factors  such  as  velocity,  turn- 
rate,  thrust,  and  position.  The  BDS  specification  also 
states  that  the  software  shall  be  developed  in  the 
"full"  Ada  language.  No  assembly  language  is 
permitted.  Ada  “code"  statements  may  be  used,  but 
are  limited  to  a  total  of  fifty.  All  application 
concurrency  is  expressed  using  the  Ada  tasking 
model  (rendezvous)  exclusively.  The  system 
includes  heavy  computational  requirements  sueh  as 
square  roots,  tangent,  and  arc  tangent,  and 
rockct/iargct  correlation.  Also  communication  with 
the  underlying  network  implementation  is  stressed. 

The  BDS  is  a  hard  deadline  driven 
application  •  failure  to  meet  liming  requirements  will 
result  in  mission  failure.  The  total  system  demand  is 
a  combination  of  rocket  guidance,  graphics  display 
update,  and  operator  interface  requirements. 

PROJECT  IMPLEMENTATION 

The  implementation  of  the  demonstration 
project  was  accomplished  by  a  team  consisting  of 
contractor  and  government  personnel.  The  BDS  and 
distribution  effort  was  done  by  the  contractor  with 
the  simulator  being  developed  by  the  government, 
'flte  development  was  at  geographically  separate 
locations.  The  contractor's  facilities  were 
approximately  150  miles  from  the  government 
installation.  Although  frequent  trips  and  phone 
conversations  were  used  as  well  as  electronic  mail, 
the  coherency  of  a  complex  design  is  difficult  to 
maintain  in  this  type  of  environment.  Nigh  speed 
modems  were  installed  to  reduce  computer-to- 
computer  delays  and  shared  access  to  a  development 
system.  Even  with  these  sendees,  it  was  generally 
felt  that  the  project  suffered  from  communication 
errors.  Due  caution  should  be  exercised  whenever 
multiple  design  sites  arc  planned  for  software 
development. 

The  design  approach  is  time/risk  driven  to 
address  the  areas  first  that  are  perceived  as  most 
difficult.  This  software  design  technique  is  targeted 
for  hard  real-time  embedded  applications  where  the 
most  difficult  aspect  of  the  project  is  meeting  the 
timing  requirements.  In  these  applications,  the 
correct  functioning  of  the  system  depends  on  proper 
liming  as  much  as  the  correctness  of  the 


calculations.  A  key  component  of  the  method  is  to 
prototype  those  algorithms  that  arc  known  to  be 
requited  in  the  system,  but  their  execution  time  is 
difficult  to  accurately  estimate.  lire  resulting 
prototype  data  is  used  to  develop  timing  budgets  and 
design  a  software  structure  to  insure  correct  timing. 
Emphasis  Is  placed  on  meeting  software  deadlines 
first,  and  to  get  the  exact  functionality  later. 
However,  functionality  must  be  sufficiently  correct  to 
ntodcl  the  timing  accurately.  This  approach  is  driven 
by  previous  experience  that  it  is  often  much  easier  to 
"fix"  the  functionality  rather  than  the  performance. 
But  another  way,  it  can  be  extremely  difficult  to 
improve  the  performance  of  a  system  that  is  grossly 
out  of  specification.  Systems  that  arc  initially  five  to 
twenty  times  too  slow  arc  not  uncommon  and 
frequently  result  In  complete  redesign.  This  places 
timing  on  top  of  the  "risk"  list.  When  the 
functionality  of  some  processing  is  not  well 
understood,  these  are  also  appropriate  areas  to 
prototype.  Prototypes  may  be  utilized  in  the  final 
product  providing  they  arc  upgraded  to  insure 
compliance  with  coding  styles.  The  process 
associated  with  the  design  method  used  is  described 
as  the  Ada  lime  Oriented  Method  (ATOM).  By 
knowing  the  difficulty  of  the  real-time  aspect,  the 
program  can  be  written  to  maximize  maintainability 
while  still  meeting  the  performance  objectives.  Hie 
general  philosophy  is  to  always  have  a  spectrum  of 
choices  to  select  from  that  provide  increasing 
performance,  at  the  sacrifice  of  memory,  complexity, 
and  case  of  maintenance.  A  program  that  is 
maintainable  but  docs  not  function  because  of 
performance  problems  is  just  as  useless  as  a 
program  that  functions  but  is  not  maintainable.  Both 
objectives  are  essential. 

The  implemented  application  code  consisted 
of  3,200  lines  of  Ada  and  31  code  statements.  There 
were  31  library  units/subunits  containing  eleven 
tasks,  one  of  which  was  an  interrupt  handler.  The 
runtime  code  to  support  distribution  was  900  lines  of 
assembly  language.  This  was  done  to  be  compatible 
with  the  vendor  supplied  runtime  which  was 
implemented  entirely  in  assembly  language.  Tire  top 
level  design  of  the  BDS  is  shown  in  Figure  1. 


PROBLEMS  AND  SOLUTIONS 

The  most  crucial  demand  for  real-time 
performance  came  from  rocket  guidance 
requirements.  To  achieve  the  accuracy  necessary  to 
correct  for  flight  trajectory  errors  and  target 
acceleration,  each  of  twenty  rockets  had  to  be 
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provided  new  guidance  aimpoims  every  l(X)ms. 
Fixed  point  calculations  were  used  to  improve 
processing  throughput.  Previous  experience  had 
provided  warning  that  it  was  difficult  to  get  fixed 
point  numbers  with  a  'SMALL  that  is  not  a  power  of 
two  (most  implementations  restrict  representation 
clauses  on  'small  to  a  power  of  two).  Therefore,  it 
was  imposed  on  the  system  design  that  the 
hardware  provided  all  dimensions  as  a  power  of  two 
value. 

Another  task  that  was  throughput  intensive 
was  the  graphics  display  update.  Although  much 
less  computation  oriented  then  rocket  calculations, 
the  sheer  volume  of  transactions  made  real-time 
response  difficult.  With  100  targets,  20  rockets,  a 


reticle,  and  statistic  information  each  being  revised, 
as  many  as  1,235  screen  updates  per  second  were 
required.  An  update  consists  of  erasing  and 

redrawing  a  symbol  containing  between  six  and 
thirty-three  pixels.  This  provided  an  average  pixel 
write  time  of  20,600  pixcls/sccond  or  48us/pixcl. 
Ibis  was  the  only  place  where  inline  code 
statements  were  utilized  for  performance.  These 
statements  provided  variable  shift  operations  that 
eould  not  be  achieved  with  the  Ada  code  generator. 

Finally,  the  operator  pointing  device  imposed 
the  most  severe  interrupt  response-time 
requirement.  To  achieve  a  system  specification  of  a 
50ms  update  rate,  the  hardware  had  to  be  configured 
to  respond  every  28ms  with  a  five  byte  data  stream 
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at  a  rate  of  2ms/bytc.  The  solution  was  to  use  an 
implementation  dependent  interrupt  handler  pragma 
to  execute  the  interrupt  code  without  a  full  task 
context  switch.  As  data  from  the  pointing  device 
was  collected,  a  small  amount  of  processing  was 
performed  in  the  interrupt  routine  and  the  time 
consuming  functions  were  off-loaded  to  a  background 
buffer  task. 

Some  of  the  major  problems  encountered  were 
because  the  “extended*  features  of  Ada  are  not 
widely  used  and  they  have  the  greatest  number  of 
anomalies.  The  notable  ones  are  as  follows: 

1)  LONG.FIXBD  division  was  unreliable. 
Cenain  numbers  (resulting  itt  bit  patterns  very  dose 
10  iFFFFn)  caused  divide  error.  This  was 
manifested  by  causing  a  NUMERIC-ERROR  after 
hours  of  operation  and  hundreds  of  rocket  launches 
and  target  intercepts.  It  was  solved  by  using  an 
exception  block  which  altered  the  expression  slightly 
and  recomputed  the  value; 

2)  There  was  improper  inlining  of  code 
statements.  If  the  last  instruction  of  the  calling 
„xjuencc  used  the  sail*;  register  as  the  first 
Instruction  of  the  machine  code  procedure  to  be 
Mined,  the  code  generator  would  exchange  the  two 
instructions,  for  example, 

mov  (t'p.lO).cx 

moves,  Up-20)  -code  statement  begin 

would  become 

mov  ex,  (bp-20) 

r.iov  |bp-IO|,cx  ••reordered,  results  In  storing 
-Incorrect  value. 

Note  that  this  problem  appeared  after  the  code  in 
question  had  already  undergone  successful 
integration  testing,  i.e.  after  a  re-compilation  caused 
different  registers  to  be  used  (with  no  changes  in 
compiler  switches).  The  solution  was  to  use  "mov 
ex,  ex"  which  can  be  re-ordered  with  no  effect; 

3)  Complex  expressions  did  not  always 
generate  the  correct  code  sequence.  Actual 
parameters  containing  array  aggregates,  which  in 
turn  consisted  of  multidimensional  array  references 
with  non-integer  subscripts,  resulted  in  a  failure  for 
the  appropriate  segment  register  to  be  loaded 
correctly.  The  graphics  task  takes  a  parameter  list 
consisting  of  the  old  and  new  positions  of  an  object 
(x.y),  the  object  type  (rocket,  target,  etc.),  and  a 
color.  To  determine  the  color,  an  array  indexed  by 
the  object  type  was  used  in  one  dimension  and  a 
status  flag  indicating  if  it  was  engaged  for  intercept 
was  used  in  the  other  dimension.  This  causes 
targets  to  "light  up"  when  engaged  for  intercept. 
However,  it  did  not  work  and  the  code  was  rewritten 
to  create  temporaries  during  each  step  of  the 


expression.  The  failure  mode  was  to  select  the  zero 
color,  black,  which  gave  the  appearance  that  nothing 
was  working,  when  in  fact  invisible  targets  were 
moving  on  the  screen; 

4)  The  pragma  to  establish  task  storage  size 
did  not  function.  This  resulted  in  the  program 
terminating  before  initial  elaboration  was  complete. 
Tire  program  would  simply  erash  with  no  exception 
trace  back  due  to  the  fact  that  the  program  had  not 
completed  elaboration.  This  required  single-stepping 
through  the  code  to  locate  the  problem.  The  solution 
was  to  use  a  linker  option  to  set  the  library  stack 
size,  although  it  then  applied  the  same  stack  size  for 
all  library  (asks;  and 

5)  Package  CALENDAR  elaboration  check 
was  not  performed  properly.  A  number  of  problems 
with  elaboration  were  encountered  due  to  library 
tasks  starting  execution  before  other  units  were 
elaborated.  One  strange  problem  was  caused 
because  no  elaboration  check  was  performed  prior  to 
calling  the  CALENDAR.CLOCK  function  to 
establish  the  periodic  start  point.  Apparently  the 
CALENDAR  package  body  had  not  been  elaborated 
and  the  CLOCK  function  returned  the  time  of  a  few 
hundred  microseconds  of  mission  time.  Then  after 
the  calling  iask  was  suspended  for  a  rendezvous  the 
CALENDAR  package  was  elaborated,  which  set  the 
TIME  value  to  some  time  in  1987  (a  very  large 
number).  When  the  task  resumed  execution,  it 
reached  the  end  of  its  loop  and  attempted  to  compute 
the  delay  necessary  to  achieve  the  desired  interval. 
Since  the  delta  time  was  almost  2,000  years,  it 
exceeded  tire  range  of  duration  and  a 
NUMER1C.ERROR  was  raised  (although  a 
T1ME.ERROR  should  have  been  raised). 

Finally,  a  problem  with  the  Ada  language 
surfaced.  There  arc  no  provisions  to  perform  a 
sequence  of  application  statements  and  a  runtime 
service  such  as  ACCEPT  without  the  possibility  of 
intervening  preemption.  The  application  has  a 
requirement  to  accept  frequent  interrupts,  buffer  the 
data  to  a  certain  point  (based  on  the  input  stream), 
and  then  perform  a  considerable  amount  of 
processing  on  the  data,  while  new  data  is  arriving. 
This  is  done  by  having  an  interrupt  task  perform  the 
buffering,  then  passing  the  data  off  to  a  background 
task.  The  problem  is  that  the  intemipt  task  may  not 
be  suspended  for  any  reason  other  than  to  service 
higher  priority  hardware  interrupts.  This  implies  that 
a  conditional  rendezvous  is  required.  However,  what 
is  really  required  is  the  ability  to  queue  the  buffer  and 
request,  then  signal  the  background  task  if  it  is 
suspended  waiting  for  new  data.  Essentially  there 
are  two  approaches  to  handling  this  problem:  1) 
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provide  a  sufficient  number  of  buffer  tasks  so  that 
they  can  act  as  surrogates  on  the  entry  queue  of  the 
background  task,  or  2)  maintain  a  flag  that  is  only  set 
when  the  buffer  task  is  ready  to  immediately  aeccpt  a 
rendezvous.  This  requires  that  the  background  task 
disable  any  type  of  preemption,  check  if  there  is  more 
work  to  do,  and  if  not,  perform  the  accept  statement. 
Presumably  the  runtime  will  then  allow  preemption 
only  after  placing  the  background  task  in  a  position  to 
immediately  accept  the  rendezvous.  The  interrupt 
task  obviously  will  no;  attempt  a  rendezvous  with 
the  background  task  unless  the  flag  is  set.  Doth  of 
these  solutions  have  serious  drawbacks.  The 
surrogate  task  approach  requires  substantial 
optimization  on  the  part  of  the  compiler  and  runtime. 
Furthermore,  it  may  make  it  less  clear  about  the 
intent  of  the  various  rendezvous.  The  second 
approach  is  very  implementation  dependent,  and  is 
prone  to  error  if  used  by  other  titan  very  experienced 
and  careful  programmers.  What  Is  dearly  needed  is 
a  simple  asynchronous  form  of  task  communication. 
Perhaps  a  standard  pragma  designating  a  task  as  a 
surrogate,  in  which  a  call  to  its  entry  is  guaranteed  to 
have  the  same  effect  as  a  ’signal"  to  the  third  piny 
task  would  be  a  solution.  To  depend  on 
implementation  optimizations  for  such  a  crucial  real¬ 
time  operation  is  a  poor  approach  to  language  design. 


PRINCIPLE  FINDINGS 

Some  of  the  principle  findings  of  this  project 
arc  as  follows: 

1)  Although  Ada  compilers  are  near  to  being 
"full"  implementations  of  the  language,  some  of  the 
most  complex  features  may  not  be  sufficiently 
reliable  for  life-critical  applications.  Several  errors  in 
runtime  code  have  been  detected  under  special 
operating  conditions.  These  conditions  include 
essentially  random  coincidence  of  executing  groups  of 
instructions  while  an  external  event  invokes  a 
context  switch.  Tills  type  of  error  may  go  undetected 
after  years  of  operation,  only  to  result  in  total  system 
failure  at  a  particular  instant; 

2)  The  execution  rate  of  both  generated  code 
and  the  runtime  code  is  considerably  better  than  that 
of  compilers  of  1986.  However,  checking  code 
remains  verbose.  This  will  tempt  real-time 
application  developers  to  suppress  the  checks,  which 
has  a  consequence  of  taking  different  paths  through 
the  code  generator.  Since  these  paths  may  not  have 
been  tested  as  thoroughly  as  the  primary  path,  the 
resulting  code  could  be  less  reliable. 

3)  Design  for  distribution  must  have  some 


initial  consideration,  but  docs  not  require  detailed 
information  regarding  the  configuration  of  the  target 
hardware,  i.c.  the  number  of  processors.  Limiting  the 
amount  of  shared  data  is  a  general  objective  to 
facilitate  distribution.  To  fully  utilize  all  available 
processors,  a  design  should  implement  independent 
activities  of  reasonable  size  as  tasks  rather  than  as 
procedures.  If  one  complex  sequence  of  calculations 
is  not  dependent  on  a  previous  set,  it  potentially 
could  be  done  on  more  than  one  processor. 
“Reasonable"  must  be  defined  as  a  function  of  the 
overhead  associated  with  a  rendezvous  as  compared 
with  a  procedure  call,  weighed  against  the  execution 
time  of  the  activity. 

4)  A  software  manager  should  not  use  Ada  on 
a  serious  real-time  project  without  source  code  to 
the  runtime.  This  is  not  for  the  purposes  of  modifying 
it,  but  to  understand  its  detailed  execution  when 
necessary.  Tills  information  is  not  available  even  In 
the  best  vendor  documentation  (which  is  often 
ineorrcet  anyway)  and  can  only  be  verified  by 
examining  the  source  of  the  runtime; 

5)  The  Ada  rendezvous  lnodcl  is  practical, 
although  not  necessarily  ideal,  for  distributed 
communication.  Unconditional  rendezvous  with  small 
parameter  lists  can  be  achieved  with  off-the-shelf 
communication  hardware  in  under  Ints.  Although 
this  is  significantly  higher  than  the  lOOus  required  for 
local  rendezvous,  it  is  still  acceptable  for  many 
applications.  More  complex  rendezvous  mechanisms 
such  as  timed  entry-  calls  and  selective  waits  with 
delay  alternatives  impose  substantial  additional 
overhead.  As  with  non-distribuicd  applications,  the 
synchronous  nature  of  the  Ada  rendezvous  imposes 
additional  task  constructs  in  order  to  "uncouple" 
many  inter-task  communications; 

6)  In  programs  using  tasks,  default  values  for 
task  stack  size  and  task  priority,  as  well  as  compiler 
selected  elaboration  order  arc  unlikely  to  be  suitable 
for  most  application*  ln«'ead,  designers  should 
explicitly  specify  values  for  all  task  priorities  and 
storage-size.  Also  the  appropriate  elaboration  order 
must  be  conveyed  to  the  compiler  via  the  Elaborate 
pragma; 

7)  The  impact  of  having  many  failures  in  the 
runtime  and  generated  code  is  demoralizing  to  the 
engineering  staff.  It  becomes  apparent  that  the  most 
difficult  problems  to  find  are  those  of  the  runtime  and 
generated  code,  since  one  expects  the  Ada  to  work 
as  specified.  No  nutter  how  good  the  developers 
arc,  the  system  will  not  work  if  it  won’t  do  what  it  is 
instructed  to  by  the  Ada  source  code.  This  is 
unusual  for  real-time  programmers  who  arc  familiar 
with  assembly  language  where  there  are  far  fewer 
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discrepancies  between  the  source  and  generated 
code; 

8)  The  speed  improvement  of  distributed  Ada 
is  net  necessarily  sealable.  Although  the  parallel 
nature  of  embedded  applications  make  them  ideal  for 
multiple  processors,  the  individual  tasks  arc  not 
usually  balanced  in  processor  loading.  On  a  shared 
memory  multi-processor,  scheduling  can  occur  on  a 
"next  available  processor"  basis  but  this  is  usually 
not  practical  on  a  distributed  system  due  to  the 
locality  of  data.  The  "vectorized  task"  is  a  partial 
solution  to  this  problem.  To  implement  the  guidance 
operation  for  tip  to  twenty  simultaneous  rocket 
trajectories,  an  array  of  tasks  was  used.  The  actual 
size  of  the  array  was  controlled  by  a  configuration 
parameter.  Bach  task  in  the  array  was  passed  a  list 
of  rockets  to  guide.  If  additional  processors  become 
available  the  size  of  the  array  an  increase  and  the 
taiks  can  be  distributed.  The  size  of  the  individual 
“work"  lists  for  each  task  would  decrease 
correspondingly,  'litis  achieves  a  "near  sealable" 
performance  increase  as  processors  are  added; 

91  Achieving  distributed  Ada  via  pre¬ 
processing  the  source  code,  or  post-processing  the 
generated  codc/nmiime  is  acceptable  for  research, 
but  unlikely  to  be  usable  for  a  production 
environment.  What  is  really  needed  is  an  integrated 
compilcr/linker/tcstcr  that  supports  distribution.  An 
ideal  compilation  system  would  support  a  hybrid 
approach  of  distribution,  i.e.  clusters  of  shared- 
memory  multiprocessors  connected  by  a  network: 

10)  Sonic  aspects  of  the  Ada  language 
definition  arc  silent  about  what  should  happen  in  a 
distributed  system.  For  example,  if  a  node  fails, 
should  future  rendezvous  to  a  task  in  that  node  get 
TASKING.BRROR  or  simply  deadlock?  What  about 
a  rendezvous  already  in  progress  with  a  failed  node? 
What  if  the  node  fails,  but  then  returns  to  service? 
These  arc  all  likely  scenarios  in  typical  distributed 
systems.  Another  area  is  die  interpretation  of  the 
timed  entry  call.  If  the  delay  duration  is  greater  than 
0.0  and  yet  the  delay  expires  prior  to  a  message 
being  sent  to  the  remote  task,  should  the  rendezvous 
be  terminated  even  if  the  accepting  task  is  ready  for 
an  "immediate"  rendezvous?  A  clear  statement 
about  what  can  be  expected  in  these  situations  (or 
possibly  control  over  what  happens  via  pragmas)  is 
necessary  in  future  language  revisions.  Although 
many  of  these  have  been  identified  previously,  no 
resolutions  have  been  adopted  and  it  is  hoped  that 
this  work  will  shed  some  insight  into  how  they  may 
be  resolved  in  future  interpretations/revisions  of  the 
language; 


CONCLUSIONS 

The  latest  release  of  Ada  compilers  are  now- 
supporting  the  features  required  for  real-time 
embedded  applications.  Performance  of  Ada  tasking 
operations  is  better  than  an  order  of  magnitude  over 
compilers  of  just  a  few  years  ago  and  optimizations, 
such  as  the  execution  of  interrupt  tasks  without  the 
cost  of  a  full  task  switch,  arc  now  available  with  very- 
good  execution  performance.  As  with  any  new 
software  product,  these  new  features  must  be  used 
with  special  attention  to  insure  that  they  perform  as 
expected.  Users  should  anticipate  that  these 
features  may  be  less  reliable  as  compared  to  more 
tested  features,  until  they  have  received  the  usage 
necessary  to  work  out  small  anomolics. 

The  use  of  Ada  tasking  constructs  for 
distributed  processing  extends  the  benefits  of 
compiler  checking  and  a  uniform  mode!  of  concurrency 
beyond  individual  processors.  Flexibility  is  enhanced 
since  migration  of  function  from  one  processor  to 
another  is  now  restricted  only  by  communication 
requirements,  which  arc  being  reduced  substantially 
by  the  next  generation  of  fiber-optic  data  links. 
Using  distributed  Ada  to  help  relieve  the  processing 
requirements  on  a  single  processor  appears  to  be  a 
viable  solution  for  many  real-time  applications. 
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MODIFICATION*  OF  LU  FACTORIZATION  ALGORITHM  FOR  PARALLEL 
PROCESSING  USING  TASKS  SUPPORTED  BY  ADA  LANGUAGE 
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An  Algunthn  to  factor  a  given  non- 
singular  natrix  A  into  two  Lower  and 
Upper  triangular  matrices  is  modified  so 
that  the  Lower  triangular  matrix  can 
be  computed  by  one  cask  and  the  Upper 
triangular  matrix  can  he  computed  hy  a 
second  task,  with  both  tasks  running  in 
parallel . 


Existing  Serial  Algorithm: 

To  transform  an  NxN  nonsingular 
natrix  A  into  the  product  of  two  matrices 
L  and  U,  where  L  is  a  lower  triangular 
matrix  and  U  is  an  upper  triangular 
matrix  with  l's  on  its  main  diagonal,  the 
Algorithm  used  is  as  follows: 

DO  FOR  I  *  1  to  N 
LCI.l)  *  A ( 1,1) 

END  DO(I). 

DO  FOR  J  ■  1  to  N 

U(1,J)  *  Atl.J)  l  1.(1, 11 

END  DO(J). 

DO  FOR  I  *  2  to  N 
DO  FOR  J  ■  I  to  N 

DO  FOR  K  '  1  to  (l-l) 
accumulate  the  SUM  of 
LU.Ki  *  U(K,  I ) 

END  DOCK) • 

L( J , I )  ■  A( J , X )  -  SUM 
END  DO(.I). 

UCI.U  »  1. 

DO  FOR  J  -  (1*1)  to  N 
DO  FOR  K  «  1  to  (1-1) 
accumulate  the  SUM  of 
L(I,K)  •  U(K.J) 

END  DOCK). 

U(I,J)  *  I  Ad.  J)  -  SUMI  /  LU,I) 
END  DOC J ) . 

END  DOC  I ) . 

In  this  algorithm,  at  each  step  I, 
where  I*  1  ..  (N-l),  a  column  of  L,  the 
lower  triangular  natrix  is  computed  first 
followed  by  a  row  of  U,  the  upper  trian¬ 
gular  matrix  in  a  serial  node.  This 
process  is  continued  until  all  the 
columns  of  the  lower  triangular  matrix 
and  all  the  rows  of  the  upper  triangular 


matrix  are  computed. 

At  the  Ith  step,  to  compute  the 
Ith  column  of  t.,  the  algorithm  requires 
the  elements  LCJ.K),  where  J»  I  ..  N,  K  « 
1  ..  CI-1);  and  the  elements  UCK,I), 
where  K  -  1  ..  CI-1).  To  compute  the  Ith 
row  of  U,  the  algorithm  requires  the  ele¬ 
ments  !,C1,K),  where  K  *  1  . .  CI-1)}  id 
the  elements  U(K,J),  where  K  «  1  ..  ti¬ 
ll;  J  *  Cl»l>  ..  N. 

For  example,  if  A  is  a  5x5  natrix 
and  we  are  at  the  stage  to  compute  the 
third  column  of  L  and  the  third  row  of  U, 
•he  computation  of  the  third  column  of  I, 
Is  as  follows: 


1.(3, 3) 

*  AC3.3)  * 

IL(3,1) 

• 

U  ( 1 , 3  >  * 

1.(3, 2) 

• 

U(2, 3) 1 

1.(4, 31 

*  A( 4 , 3)  - 

IL(4.1) 

• 

0(1,3)  * 

1.(4, 2) 

• 

Ut  2 , 3 )  1 

L(5,3) 

*  A  ( 5 , 3 )  - 

!L(5,1) 

• 

Ui 1.3)  ♦ 

1,(5, 2) 

• 

U(2,3) ! 

The  computation  of  the  third  row  of  'J  is 
as  follows: 

U(3,4)  r  IAC3.4)  -  1LC3.1)  *  U C 1 , 4 )  • 
LC3.2)  •  U ( 2 , 4 ) 1 1  /  LC3.3) 

0(3,51  *  I A ( 3 , 5 )  -  ILC3.1)  *  UC1,5)  ♦ 
LC3.2)  *  U ( 2 , 5 >  1 1  /  1,13,3) 


Requirements  for  a  Parallel  Algorithm: 

The  analysis  of  the  above  computations 
shows  that  the  computation  of  the  third 
column  of  L  uses  the  elements  U(l,3)  of 
the  first  row  of  U  and  OC2,3)  of  the 
second  row  of  U.  It  docs  not  require  any 
clcnent  of  the  third  row  of  U.  Similarly, 
the  computation  of  the  third  row  of  U 
uses  1,(3, 1)  of  the  first  column  of  L, 
L(3,2)  of  the  second  column  of  L  and 
L(3,3)  of  the  third  column  of  L.  If  L  is 
computed  by  one  task,  (task  LOWER),  and  U 
is  computed  by  another  task,  (task 
UPPER),  in  parallel,  then  at  the  third 
step,  task  LOWER,  computing  the  third 
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column  o£  L  doc*  not  require  any  informa¬ 
tion  from  the  task  UPPER,  computing  Che 
third  row  o£  U,  provided  that  task  UPPER 
ha*  communicated  the  result*  of  it*  com¬ 
putation*  of  the  first  and  second  row*  to 
task  LOWER  before  it  begin*  computation* 
for  the  third  row  of  U.  Ta*k  UPPER  doe*, 
however,  require  the  value  of  t<(3.3)  from 
task  LOWER,  computing  the  third  column  of 
L.  Thl*  I*  the  first  and  only  element 
whose  value  i*  needed  by  ca*k  UPPER  for 
the  computation  of  the  third  row  of  U 
from  task  LOWER. 

There  are  two  mean*  by  which  this 
requirement  may  be  facilitated! 

tit  After  task  lOWER  has  completed  the 
computation  of  L(3,3),  it  nay  communicate 
the  value  of  L(3,3>  to  task  UPPER  and 
then  compute  the  rest  of  the  third 
column. 

(2)  Task  UPPER  computes  the  value  of 
L(3,3)  by  itself  and  does  not  watt  on 
task  LOWER  to  communicate  to  it. 

It  is  assumed  here  that  each  task, 
UPPER  and  LOWER,  communicates  the  results 
of  its  row  and  column  computations,  to 
the  other  task,  before  it  starts  on  the 
next  row  or  column.  Either  of  these 
alternatives  will  then  allow  task  LOWER 
to  compute  the  third  column  of  L  and  task 
UPPER  to  compute  the  third  row  of  U  in 
parallel.  The  second  alternative  is  the 
more  desirable  one  for  the  following 
reasons: 

(1)  Task  UPPER  does  not  have  to  wait 
for  task  LOWER  to  communicate  this 
result. 

(2)  It  reduces  the  communications  be¬ 
tween  the  two  tasks. 

(3)  Task  LOWER  can  skip  the  computa¬ 
tion  of  L(3,3),  because  it  does  not  need 
it  for  the  computation  of  the  third 
column  of  L. 

This  situation  is  true  for  every  Ith 
column  of  L  and  Ith  row  of  U,  where  1*2 
..  (N-l ) . 

At  the  Ith  step,  where  1*2..  tN- 
1),  task  LOWER  has  to  compute  (N-I) 
elements  of  the  Ith  column  of  L  and  task 
UPPER  has  to  compute  (N-I)  elements  of 
the  Ith  row  of  U.  Computations  of  these 
elements  do  not  depend  on  each  other  and 
it  can  also  be  accomplished  in  parallel 
using  several  tasks  by  each  LOWER  and 
UPPER  tasks.  Communications,  between  the 
LOWER  and  UPPER  tasks,  required  to  pass 
the  results  of  the  computations,  can  be 
further  reduced  if  the  factors  L  and  U  of 
A  are  stored  in  matrix  A  (in  place) 


rather  than  in  separate  matrices  L  and  U. 
This  will  require  matrix  A  to  he  declared 
as  a  global  variable  (shared  variable) 
for  the  LOWER  and  UPPER  tasks.  This  will 
eliminate  the  need  for  communications  be¬ 
tween  the  two  tasks  as  the  computations 
of  each  row  and  each  column  are  avail¬ 
able.  Each  task  will  still  bo  required  to 
communicate  with  the  other  task  to  indi¬ 
cate  that  it  ha*  completed  computation  of 
the  column  or  row  that  it  wa*  working  on 
before  it  starts  to  compute  the  next 
column  or  row.  Numerical  experiment*  to 
compare  the  CPU  time  of  these  various 
approaehe*  with  different  size  matrices 
are  in  progress.  The  re*ult*  of  the*e 
studies  should  he  available  by  the  next 
Joint  Ada  meeting.  The  modified  algo¬ 
rithm  for  LU  FACTOR  I  EAR  I  ON,  using  in 
place  storage  of  I.  and  u,  and  it*  im¬ 
plementation  in  Ada  language  are  1  luted 
below. 

Modified  LU  FACTORIZATION  Algorithm  : 
Degin 

Taak  LOWER: 

X.  Accept  N,  the  size  of  matrix  A. 

2.  Create  taak*  X(I>,  I  *  1  ..  (N-2) 
to  compute  the  element*  of  a 
column  of  the  lower  triangular 
matrix. 

3.  Compute  U(l,21,  the  second  element 
of  the  first  row  of  U  and  store  it 
in  A ( 1 , 2 ) . 

All,  2)  *  All,  2)  /  All.l) 

4.  Compute  the  columns  of  the  lower 
triangular  matrix 

DO  FOR  1*2..  (N-l) 

4 . 1  DO  FOR  J  ■  (1*1)  ..  N 

CALL  task  X(J-2)  to  compute 
the  I,(J,I)  clement  of  I.. 

END  DO(J). 

4.2  DO  FOR  J  *  (1*1)  ..  N 

CALL  task  XtJ-2)  to  check 
whether  it  has  completed  the 
computation  of  the  element 
L( J ,  I ) . 

END  DO( J)  . 

4.3  Rendezvous  with  task  UPPER  to 
check  whether  it  has  completed 
the  computation  of  row  I. 

4.4  End  the  task  X(I-l)  which  is  no 
longer  needed. 

END  DO(I). 

5.  Compute  A(N,N). 
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DO  FOR  K  <  1  ..  (N-l) 

accumulate  the  SUM  of 
ACJ5.K)  *  A<  K,N) 

ENO  DQ(K). 

A(S.N')  *  A C N , H 1  -  SUM. 

G.  Communicate  matrix  A  to  the 
ealSing  program. 

END  tank  DOWER, 


Task  UPPER: 

1.  Accept  N,  Che  »ixe  of  matrix  A. 

2.  Create  tanka  YU).  I  «  1  ..  (N-2) 
to  compute  el  omenta  of  .i  row  of 
upper  triangular  matrix. 

5.  Compute  the  Cirat  row  of  U  and 
store  it  in  the  firat  row  of  A. 
All,  3..N)  ♦  All,  3..N)  /  All. II 

4.  Compute  the  rowa  of  the  upper  tria¬ 
ngular  matrix 

1)0  FOR  I  ♦  2  ..  (N-l) 

4.1  Compute  MT.IJ.  the  1th  row  .uid 
the  Ith  column  element  of  L. 
needed  for  computation  of  the  1th 
row  of  u.  Store  it  in  At  X « X I . 

DO  FOR  K  •  1  ..  (1-11 

accumulate  the  SUM  of 
All, HI  *  AIK, I) 

END  DOIK). 

All, I)  *  All.I)  -  SUM. 

4.2  DO  FOR  J  *  11*11  ..  N 

CALL  task  YlJ-2)  to  compute 
the  U(I,J)  clement  of  U. 
END  DOIJJ. 

4.3  DO  FOR  J  ‘  11*1)  ..  N 

CALL  task  YlJ-2)  to  check 
whether  it  has  completed  the 
computation  of  element  U(I,J). 
END  D01J1. 

4.4  Rendezvous  with  task  LOWER  to 
chock  whether  it  has  completed 
the  computation  of  ti  *  column  I. 

4.5  End  the  task  Yll-l)  which  is  no 
longer  needed. 

END  DOlI). 

END  task  UPPER 


Tasks  XU)  and  Yll),  1  ■  1  ..  (N-2): 

1.  Accept  the  indices  J  and  K  of  the 
element  to  be  computed  and  the  in¬ 
dex  L_OR_U  for  LOWER  or  UPPER 
matrix.  ** 


2.  Compute  the  element  L(J.K)  or 
UtJ.K)  and  ntorc  it  in  A(J,K). 


2.1  If  element  of  L  (L  OR  0*0)  then 
IX)  FOR  K1  *  1  ..  IK-1) 

accumulate  the  SUM  of 
AlJ.Kl)  *  A(Kl.K) 

END  D01K1). 

AIJ.KJ  «  AlJ.Kl  -  SUM. 
else 


(1,  QU  U«l) 

DO  FOR  K1  ■  1  ..  (J-l) 

accumulate  the  SUM  of 
AlJ.Kl)  *  AlKl.K) 

END  DO(Kl). 


AlJ.Kl  *  l.MJ.K) 
end  if. 


-  SUMI  / 
A(J.J) 


3.  Accept  Lite  index  of  the  task  X  or 
task  Y  to  check  completion  of  the 
computation. 

4.  accept  index  1  to  stop  task  XU)  or 
Yll). 


END  task  XII)  or  Yll). 


Ada  Code: 
generic 

DOUND  :  in  INTEGER; 

package  LU_DF.COMP_ROUTINESLL  is 

type  MATRIX  is 

arrayll  ..  DOUND,  1  ..  DOUND)  of  FLOAT; 
procedure  LU  DECOMP (A  :  in  out  MATRIX; 

DOUND  :  in  INTEGER); 

end  LU_DECOMP  ROUTINESLL; 


A 


package  body  LU_DECOMP_ROUTINESLL  is 

—  Procedure  to  factor  a  given  matrix 
procedure  I,U  DECOMPIA  :  in  out  MATRIX; 

DOUND  :  in  INTEGER)  is 

LU_DONE  :  DOOLEAN  : »  FALSE; 

SINGULAR  :  exception; 


—  procedure  to  compute  the  sum  of 
AlINDXl.K)  *  AIK, INDX2) 
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—  for  row  and  column  elements 
procedure  SUM* 

1X0X1,  1X0X2  LIMIT  :  in  INTEGER; 

S  :  in  out  FLOAT); 

—  task  to  compute  LOWER  TRIANGULAR 

FACTOR 

task  LOWER  is 

entry  X  IN  LOWER { 

00UX0  :  in  INTEGER  ); 

entry  STOP  LOWER* 

LUJXJNB  :  in  BOOLEAN); 

end  LOWER; 


-  task  to  compute  UPPER  TRIANGULAR 

FACTOR 


task  UPPER  is 

entry  N  IN  UPPER* 

DOUND  :  in  INTEGER); 

entry  ROW  COLUMN  CHECK* 

COLUMN_DONE“:  out  BOOLEAN); 

entry  STOP  UPPER* 

LU  DONE  :  in  BOOLEAN); 

end  UPPER; 


—  task  to  compute  an  element  of 

—  row  or  colunn  of  factor  matrix 

task  type  COMPUTE  is 

entry  ELEM*  FIRST,  SECOND, 

CHOICE  s  in  INTEGER); 

entry  ELEM  DONE*  DONEI 

;  out  INTEGER); 


entry  ST0P_TASK*  DONE 
end  COMPUTE; 


in  INTEGER); 


—  body  of  the  procedure  SUM 
procedure  SUM*  INDXI,  INDX2, 

LIMIT  :  in  INTEGER; 

S  :  in  out  FLOAT)  is 

begin 

S  : «  0.0; 

for  K  in  1  . .  LIMIT  loop 
S  :«  S  +  A* INDXI ,  K)*A*K,  INDX2); 
end  loop; 
end  SUM; 


—  body  of  the  task 
task  body  LOWER  is 
N,  CHOICE  ; 

N  IN  L  : 


LOWER 

INTEGER; 

BOOLEAN  :=  FALSE; 


COLUMN  DONE 
NEXT  COLUMN 
L  DONE 
S 


BOOLEAN  :*  FALSE; 
BOOLEAN  : »  FALSE; 
BOOLEAN  :■  FALSE; 
FLOAT  : *  0.0; 


begin 

—set  index  to  compute  column  element 
L_OR_U  :«  0; 
loop 
select 

—  get  bound  in  LOWER 
accept  N  IN  LOWER* 

BOUND  :  in  INTEGER)  do 
N  :■  BOUND; 
end  N_IN_LOWER; 

--compute  second  element  of  first 

—  row  of  U  and  store  it  in  A*l,2) 

A* I,  2)  :■  A(l,  2)/AU,  1); 
N_1N_L  : »  TRUE; 


or 

delay  0.1; 

end  select; 
exit  when  N_IN_L; 
end  loop; 

declare 

—  tasks  to  compute  elements  of 

—  column  of  L 

X  s  array *1. . *N  -  2))  of  COMPUTE; 
X  DONE;  array (1. . *N  -  2))  of  INTEGER 
:*  *1  ..  IN  -  2)  »>  0); 

begin 

for  I  in  2  ..  <N  -  1)  loop 

—  begin  computations  of  elements 

—  of  Ith  coulmn  of  L  using  tasks 
for  J  in  *1  *  I)  ..  N  loop 

X* J-2) .ELEM* J,  I,  L_OR_U); 
end  loop; 

—  check  all  tasks  X  are  done 

—  with  Ith  column  of  L 
for  J  in  *1-1)  ..  N  loop 

X* J-2) . ELEM_DONE*X_DONE* J-2 ) ) ; 
end  loop; 

—  rendezvous  with  task  UPPER  to 

—  check  whether  it  has  finished 

—  computation  of  Ith  row 
UPPER. ROW  COLUMN  CHECK* 

COLUMN_DONE) ; 

—  stop  task  X  no  longer  needed 
X  DONE* I -1 )  :=  1; 

xTl-1 > . STOP_TASK ( X_DONE* 1-1 ) > ; 

—  next  column  of  L 
end  loop; 

—  last  column  of  L 
SUM*  N,  N,  N  -  1,  S); 
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AIN,  N)  :•  AIN,  N)  -  S; 

L_OONE  :»  TRUE; 

—  terminate  tank  LOWER 
loop 
select 

when  I.J50NE  ■> 

accept  STOP  LOWER t 

LU  DON’E  s  xn  BOOLEAN)  do 
L  DONE  :*  LU  DONE; 
end  STOP  LOWER; 
exit  when  L  DONE; 


or 


delay  0.1; 
end  select; 
end  loop; 
end; 

end  LOWER; 


tank  body  UPPER  in 

N<  L  OR  U 
ROW  COLUMN  DONE 
N  If?  U 
ROW  DONE 
U  DONE 

s" 


INTEGER; 

BOOLEAN  :■  FALSE; 
BOOLEAN  :*  FALSE; 
BOOLEAN  :■  FALSE; 
BOOLEAN  :«  FALSt; 
FLOAT  :*  0.0; 


begin 

—  index  to  conpute  row  element 
L_OR_U  :*  1; 
loop 
select 


—  get  bound  of  A 
accept  N  IN  UPPER ( 

BOUND  :  in  INTEGER)  do 
N  :>  BOUND; 
end  N  IN  UPPER; 

N  IN  U  :*  TRUE; 


—  compute  first  row  of  U; 
if  (A'1,1)  *  0.0)  then 
raise  SINGULAR; 
end  if; 

for  J  in  3  ..  N  loop 
All,  J)  : *  All,  J)/A(l,  1); 
end  loop; 


--  tanks  to  conpute  row  elcnetx  of  U 

Y  :  array) 1  ..  (N  -  2))  of  COMPUTE; 

Y  DONE:  array) I  . .  )N  -  2))  of  INTEGER 

:♦  II  ..  IN  -  2)  0); 

begin 

for  I  in  2  . .  IN  -  1 )  loop 

—  compute  the  first  element  of 
—  Ith  column  of  L 

SUMII,  I,  I  -  1,  S); 

All,  1)  :>  All,  I)  -  S; 

—  begin  computation  of  Ith  row 
--  of  U  using  tasks 

for  J  in  II  »  1)  ..  N  loop 

YIJ  -  2) .ELEMtl#  J,  L_OR_U); 
end  loop; 

—  check  all  tasks  Y  are  done  with 
—  Ith  row  of  U 

for  J  in  11*1)  ..  N  loop 

YIJ-2)  .ELEM_OONEIY_DONEU-2)  )  ; 
end  loop; 

R0WJ30NE  :«  TRUE; 

—  stop  task  no  longer  needed  for 

—  row  computation 
Y  DONEII-1)  :■  1; 

y7i-1) .STOP_TASK«Y_DONEtI-l) ) ; 

loop 

select 

when  (ROW_DONE  or  U_DONE)  ■> 

—  rendevous  with  task  LOWER  to 

—  check  for  Ith  row  and  column 

—  completed 

accept  ROW  COLUMN  CHECK! 
COLUMN  DONE:  out  BOOLEAN)  do 
COLUMN  DONE  :■  ROW  DONE; 
end  ROW  COLUMN  CHECK; 

U  DONE  7-  FALSE; 

ROW  DONE  :■  FALSE; 

ROW  COLUMN  DONE  :■  TRUE; 


or 

delay  0.1; 
end  select; 

exit  when  ROW_COLUMN_DONE; 
end  loop; 

ROW_COLUMN_DONE  :■  FALSE; 

—  next  row  of  U 
end  loop; 


or 


delay  0.1; 
end  select; 
exit  when  N_IN_U; 


—  all  rows  of  U  done 
U_DONE  :=  TRUE; 

—  terminate  task  UPPER 
loop 

select 

when  U  DONE  => 


end  loop; 
declare 


accept  STOP  UPPER I 

LU_DONE  :  in  BOOLEAN)  do 
U_DONE  :=  LU  DONE; 
end  STOP_UPPER; 
exit  when  U_DONE; 
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or 

delay  0.1; 
end  aelect; 
end  loop; 
end; 

end  UPPER; 

tank  body  COMPUTE  ia 

INDXi,  1NDX2,  LIMIX  :  INTEGER; 

DON EC  :  INTEGER  :«  0; 

S  s  FLOAT  s*  0.0; 

INDX  :  INTEGER  ; 

DDONE  :  DOOLEAN  :«  FALSE; 

begin 

loop 

aelect 

—  accept  the  Indices  of  the  elen- 

—  cnt  to  be  computed  and  index  for 

—  the  matrix 

accept  ELEMIFIRST,  SECOND,  L  OR  U 

s  in  INTEGER!  do 
INDX1  :*  FIRST; 

INDX2  :*  SECOND; 

INDX  :■  L  OR  U; 
end  ELEM; 

if  (INDX  ■  0)  then 

—  competing  column  element 
LIMIT  :»  INDX 2  -  1; 

SUMIINUXI,  INDX2,  LIMIT,  S); 
A(INDX1,  INDX2)  ; - 

AdNDXl ,  INDX21  -  S; 
DDONE  :■  TRUE; 

elae 

—  computing  row  element 
LIMIT  : »  INDX1  -  1; 

SUMdNDXl,  INDX2,  LIMIT,  SI; 
if  ( AdNDXl, INDX2)  *  0.0)  then 

raise  SINGULAR; 
end  if; 

AdNDXl,  INDX2)  :« 

(AdNDXl,  INDX2)  -  S>/ 

AdNDXl,  INDXI); 
DDONE  :■  TRUE; 

end  if; 


when  DDONE  *> 

—  accept  index  for  element  done 
accept  ELEM  DONE( 

DONE1  :  out  INTEGER)  do 
DONE1  :»  DONEC; 
end  ELEM_DONE; 

or 

—  accept  index  for  task  to  be 

—  stopped 
accept  STOP  TASK( 

DONE  :  in  INTEGER)  do 
DONEC  :=  DONE; 
end  STOP  TASK; 


exit  when  (DONEC  *  1); 
or 

delay  0.1; 
end  aelect; 
end  loop; 
end  COMPUTE; 

—  begin  the  LU_OECOMP  procedure 
begin 

—  pass  the  bound  of  A  to  tasks 
—  LOWER  and  UPPER 

LOWER. N  IN  LOWER (DOUNO) ; 

UPPER. n”iN_UPPER< ROUNDS  ; 

—  teminate  tasks  LOWER  and  UPPER 
LU  DONE  :■  TRUE; 

LOWER. STOP  LOWER t LU  DONE); 

UPPER . STOP_UPPKR ( LU  JXJNB ) ; 

—  abort  tasks  if  matrix  is  singular 
exception 

when  SINGULAR  ■> 

abort  UPPER,  LOWER; 
end  I.U  DECOMP: 
end  I.U  DECOMP  ROUTINRSLL; 
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Learning  Ada  From  Ada 


Lawrence  E.  Smithmier  Jr. 

University  of  Mississippi 
Undergraduate  Student  Paper 


On-lino  tutorials  can  provide  an  effective  teaching 
tool  within  a  computer  environment.  They  can  be 
designed  in  such  a  way  as  to  accommodate  users  with 
different  levels  of  knowledge  and  who  work  at  different 
paces. 

This  paper  discussos  a  tutorial  written  in  Ada  on 
an  IBM  370  using  the  Alsys  compiler.  Our  system, 
designed  and  written  using  Ada,  allows  the  users  to 
move  forward  or  backward  within  the  tutorial  because 
three  screens  (the  current  screen,  the  next  screen,  and 
the  previous  screen)  are  kept  in  memory  by  background 
tasks.  When  the  user  proceeds  to  anothor  screen,  a 
background  task  brings  the  next  appropriate  screen  into 
memory  while  the  foreground  task  displays  the 
requested  screen.  This  facilitates  a  quicker  response 
time  when  moving  through  the  tutorial.  A  balanco 
between  maximum  speed  and  minimum  memory  usage 
is  achieved  through  this  use  of  Ada  tasking.  Through  tho 
use  of  packages,  the  screen  driver  and  the  questionnaire 
driver  can  both  use  the  same  background  task.  Tho 
tutorial  is  written  entirely  In  Ada  using  only  one  IBM 
system  call,  done  via  a  call  to  low-level  I/O  an  Ada  library 
call  supported  In  the  LRM. 


Ada  is  very  similar  to  Pascal  in  the  types  of 
control  structures  available,  the  types  of 
operators  used,  the  use  of  subprograms,  and 
most  of  the  data  types  available.  It  docs, 
however,  have  some  subtleties  which  arc  not 
intuitively  obvious,  for  example:  it  is  important 
to  look  carefully  at  the  way  tasking  is  handled 
and  how  and  when  it  should  be  used.  It  is  also 
important  to  look  at  generics,  private  types,  and 
variable  passing. 

The  on-line  tutorial  has  been  used 
effectively  for  some  time  as  a  teaching  tool  in  a 
computer  environment  because  it  gives  the  user 
a  hands-on  feel  for  the  subject.  This  makes  such 
a  tutorial  a  natural  tool  to  teach  a  new  and 
difficult  language  because  it  will  allow  the  user 
to  determine  which  language  features  he  can 
review  and  which  lie  needs  to  study  in-depth. 

Our  tutorial  was  written  as  part  of  a 
software  engineering  course  using  Ada  as  a  too'. 


Ada  was  chosen  because  it  so  readily  supported 
software  engineering  principles.  Software 
engineering  goals  realized  by  Ada  arc: 
abstraction,  automation,  information  hiding, 
localized  costs,  portability,  preservation  of 
information,  simplicity,  and  structure. 

This  tutorial  was  the  final  group  project  of 
the  semester  and  combines  the  knowledge  we 
learned  of  both  Ada  and  software  engineering  in 
one  package.  The  tutorial  was  written  modularly 
to  aid  in  the  maintainability  of  the  code  itself.  It 
is  also  portable  because  all  but  one  command  is 
standard  Ada.  The  tutorial  also  uses  a  buffering 
package  which  provides  it  with  a  level  of 
information  hiding.  And  finally,  the  tutorial  is 
abstract  because  the  names  of  lesson  and  quiz 
files  to  be  used  arc  stored  in  a  file  which  can  be 
changed  to  add  or  delete  lessons. 

The  tutorial  was  written  in  Ada  about  Ada 
by  students  who  were  learning  Ada  as  they  were 
completing  the  assignment.  The  lessons  and 
quizzes  were  also  written  by  students  who  were 
learning  as  they  tried  to  teach  others.  This 
makes  the  tutorial  a  much  better  teaching  tool 
because  the  writers  still  remembered  what  was 
hard  for  them  to  learn  and  took  the  time  to 
present  these  topics  in  a  little  more  depth  and 
from  several  angles.  A  good  example  of  this  is  in 
the  lesson  tasking  in  which  two  program  outlines 
arc  discussed.  One  of  the  examples  is  a  program 
which  readily  fends  itself  to  tasking:  »•««»,  p.  2wi 

procedure  SHOPPING  Is 
task  GET_SALAD; 

task  body  GET_SALAD  is 
begin 

BUY  SALAD; 
end  GETJ3ALAD; 
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task  GET_WINE; 


task  body  GETJWINE  is 
begin 

BUYJVINE; 
end  GETJWINE; 


begin 


BUYJdEAT; 


end  SHOPPING; 


where  BUY  WINE.  8UY_SALA0  &  BUY_MEAT  arc 
procedures  "and  GET_WINE  &  GET_SALAD  are 
tasks.  The  other  example  shows  a  program 
which  docs  not  use  tasking  efficiently: 


sleeping,  and  getting  gas.  can  not  be  done 
in  parallel) 

If  the  user  gets  a  question  wrong  he  is  told  the 
right  answer  and  is  given  the  total  number 
missed  upon  completing  the  quiz. 

The  more  sophisticated  user  will  be  able  to 
skip  topics  he  is  well  versed  in  because  the 
tutorial  is  menu  driven  and  the  user  need  not 
review  a  subject  unless  lie  wants  to.  and  even 
then  he  is  given  the  option  to  quit  that  lesson. 
The  option  menu  looks  like  this: 

•**Ada  Tutorial"* 


procedure  FIX_A_FLAT  is 
task  TAKE_OFF_TIRE; 

task  body  TAKE_OFF_TIRE  is 
begin 

REMOVE  LUGJJUTS; 
end  TAKE_OFF_TIR£; 

task  PUT_ON_SPARE; 

task  body  PUT_ON_SPARE  is 
begin 

REPLACE  LUG_NUTS; 
end  PUT_ON_SPARE; 


GET  SPARE; 
end  FIX_A_FLAT; 

where  REPLACE_LtlG_NUTS,  REMOVE_lUG_NUTS 
Si  GET_SPARE  arc  proccduivS  and  TAKE_OFF_TIRE 
&  PUT_ON_SPARE  are  tasks. 

The  tutorial  allows  the  beginner  to  proceed 
at  his  own  pace  and  to  check  his  mastery  at  the 
end  of  each  topic  using  the  quizzes.  The  quizzes 
arc  written  as  a  scries  of  question  and  answer 
sessions  of  varying  length.  The  questions  were 
designed  to  test  the  user  on  the  concepts  we  felt 
were  essential  that  the  user  know  for  effective 
programming.  The  quizzes  arc  provided  at  the 
end  of  each  lesson  and  the  user  has  the  option  of 
taking  them  or  skipping  them.  They  are 
displayed  by  a  separate  process  from  the  tutorial 
text.  For  example,  the  tasking  quiz  presents  a 
problem  definition  and  asks  whether  tasking 
should  be  used. 


1)  OPERATORS 

2)  TYPES 

3)  CONTROL  STRUCTURES 
A)  SUBPROGRAMS 

5)  TASKING 
’6)  GENERICS 

7)  LIBRARY  UNITS 

8)  EXCEPTIONS 

Ploaso  enter  the  number  ol  the  lesson  you  would  liko  to 
run  or  a  0  to  exit: 


This  menu  allows  the  user  to  not  only  choose  the 
topics  he  will  study,  but  also  the  order  in  which 
they  will  be  studied.  The  order  in  which  they 
appear  on  the  menu  docs  represent  the  order 
which  we  felt  they  should  be  covered.  The  files 
which  are  displayed  on  the  menu  come  from  a 
file  which  holds  the  name  of  each  text  file  and 
quiz  to  be  offered.  The  form  of  the  file  is: 

OPERATORS 

OPERATOR 

TYPES 

TYPE) 

CONTROL  STRUCTURES 

CONTROL 

SUBPROGRAMS 

SPROGRAM 

TASKING 

TASKING 

GENERICS 

GENERIC 

LIBRARY  UNITS 

LIBUS 

EXCEPTIONS 

EXCEPT 

EXIT 

NOFILE 


2.  Should  tasking  be  used  in  a  program  which 
will  simulate  a  cross-country  trip  by  car, 
assuming  you  don't  need  to  eat?  (no, 
because  the  operations  left:  driving, 


where  OPERATORS  is  the  text  file  and  OPERATOR 
is  the  questionnaire  file.  The  control  word 
NO  FILE  is  used  when  no  questionnaire  is 
available  and  the  code  word  EXIT  is  used  to 
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indicate  the  end  of  the  topic  list.  This  system 
allots  the  tutorial  program  to  be  easily  updated 
or  even  changed  to  a  different  subject  entirely. 
This  can  be  done  by  simply  updating  the  file 
M_FILE  to  represent  the  current  state  of  the 
tutorial. 

The  lessons  arc  displayed  by  a  screen 
handler  which  receives  the  information  in  an 
unformatted  state  from  a  text  file.  This  increases 
the  ease  in  which  lessons  can  be  corrected  or 
replaced.  The  screen  handler  allows  the  user  to 
move  along  at  a  quick  pace  over  subjects  he  is 
somewhat  familiar  with  or  to  go  slowly  through 
those  subjects  which  he  has  not  seen  before  by 
allowing  the  user  to  decide  when  the  next  screen 
is  displayed.  It  also  gives  the  user  the  option  of 
backing  up  to  the  previous  screen,  or  even 
quittint  that  lesson  entirely.  The  lessons  in  the 
tutorial  arc  taken  from  Programming  in  .Ada 
.Second  Edition.  by  J.  G.  P.  Barnes,  and  are  listed 
roughly  in  the  same  order  as  found  in  the  book. 
The  lesson  screen  looks  like  ihisttitr***,  p.  m,« 

generic 

typo  ITEM  Is  private; 

procedure  EXCHANGE!  X.  Y:  In  out  ITEM); 

proceduro  EXCHANGE!  X,  Y:  In  out  ITEM)  is 

T:ITEM; 

begin 

T:-X;X;-Y;Y:-T; 

end; 

The  subprogram  EXCHANGE  is  a  generic  subprogram 
and  acts  as  a  kind  o(  template.  The  generic  mechanism 
takes  the  form  ol  subprogram  specification  which  is 
preceded  by  the  generic  formal  part  consisting  ol  the 
reserved  word  "gonoric"  followed  by  a  (possibly  empty) 
list  of  generic  formal  parameters.  Note  that  we  have  to 
give  both  the  body  and  the  specifications  separately. 

The  generic  procedure  cannot  be  called  directly  but  from 
it  we  can  create  an  actual  procedure  by  a  mechanism 
known  as  generic  instantiation.  For  example,  we  may 
write 

Enter  an  N,  a  P,  or  an  E  to  move  forwards,  backwards,  or 
to  exit: 

The  tutorial  is  able  to  allow  the  user  to 
back  up  through  the  use  of  a  double  buffering 
system.  One  buffer  holds  the  previous  screen, 
the  other  holds  the  next  screen,  while  the  current 
screen  is  being  displayed.  Both  the  questionnaire 
and  the  lesson  procedures  use  the  same 
buffering  system.  This  is  facilitated  through  the 
use  of  packages.  The  buffering  package 
maintains  two  twenty-one  line  buffers  at  all 


times,  while  a  third  buffer  is  held  in  the 
procedure  currently  running. 

The  tutorial  uses  two  background  tasks  to 
update  the  buffers,  thus  speeding  up  screen 
updating  and  allowing  the  user  to  move  both 
forward  and  backward  in  the  text.  One  task 
holds  the  previous  screen  while  the  other  holds 
the  next  screen.  Each  task  reads  from  the 
tutorial  text  file  and  holds  one  page  in  memory 
a(  a  time.  The  text  in  the  files  is  unformatted, 
that  is,  the  text  is  saved  in  the  files  in  the  same 
way  it  will  be  shown  on  the  screen.  The 
buffering  system  is  defined  as  a  package,  which 
is  used  by  both  the  text  and  questionnaire 
drivers.  Through  the  use  of  the  package,  we 
made  the  code  more  readable  and  more  compact. 
This  use  of  background  tasks  and  packages 
reduces  both  the  complexity  of  the  code  and  the 
amount  of  code  in  memory  during  execution. 

The  tutorial  is  written  entirely  in  Ada  using 
only  one  IBM  system  call.  The  system  call  was 
done  via  a  call  to  low-level  I/O,  an  Ada  library 
call,  supported  in  the  LKM.  This  system  call  is  a 
CLRSCRN  command,  used  to  dear  the  screen,  and 
is  accomplished  as  follows: 

EXECUTE_COMMAND('CLRSCRN‘); 

This  is  the  only  command  which  is  not  fully 
portable  to  any  Ada  machine. 

The  tutorial  was  written  and  tested  using 
the  Alsys  IBM  370  ADA  compiler  for  VM/CMS, 
version  2.3.  The  compiler  was  run  on  the 
University  of  Mississippi's  Amdahl  470/V8 
running  IBM  VM/SP  CMS  Version  4.0.  The 
Amdahl  470/V8  is  architecturally  equivalent  to 
the  IBM  3083JX. 

In  conclusion,  we  feel  that  a  tutorial 
written  for  Ada  can  be  a  valuable  teaching  tool. 
We  think  that  having  students  who  had  recently 
learned  Ada  write  a  tutorial  on  the  subject  was 
useful  because,  as  stated  earlier,  they 
remembered  what  was  difficult  for  them  to 
learn.  It  might  also  have  been  good  «o  have  Ada 
programmers  at  several  higher  levels  of 
knowledge  participate  in  (he  tutorial  design. 
They  could  have  given  insight  into  more 
advanced  implementation  strategies  used  in 
complicated  applications.  Ada  made  the  tutorial 
easier  to  write  as  a  group  because  it  supports 
separate  compilation  which  allowed  the  parts  to 
be  written  separately  and  then  combined.  The 
use  of  tasking  also  provided  quick  screen  display, 
while  packages  allowed  for  better  abstraction 
within  the  code.  Writing  this  tutorial  in  Ada 
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gave  us  a  first  hand  experience  in  how  the 
structure  of  the  language  encourages  good 
software  engineering  methods  and  shows  how 
Ada  allows  a  design  group  to  work  in  parallel. 


Barnes,  J.  G.  I*.  Programming  in  Ada.  2nd.  cd. 
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Problems  in  Using  Ada  ••  a  Davslopmsnt  Tool 


Allison  Juanita  Null 


Th«  Univarsity 


ABSTRACT 

Tha  purpose  of  this  pnpor  is  twofold: 
firstly,  to  take  n  look  nt  how  AOA  was  used 
to  support  and  uphold  tho  goals  and 
principles  of  software  engineering  within 
the  context  of  developing  a  *ajor 
interactive  tutorial  program  to  teach  ADA, 
and,  secondly,  to  describe  some  of  tho 
pitfalls  of  using  ADA  as  a  development 
tool.  Tho  prinary  problem  examined 
concerns  tho  issue  of  portability  as 
related  to  the  inplenontation  of  a  required 
function  which  could  not  be  provided  within 
the  AOA  environment.  Consequently,  this 
caused  the  tutorial  to  be  non-portable. 


(1)  INTRODUCTION  :  BACKGROUND 

Realizing  that  ADA  was  one  of  the 
most  significant  developments  in 
programming  languages  and  wanting  to 
promote  some  degree  of  ADA  literacy  at  the 
University  of  Mississippi,  one  of  the 
software  engineering  classes  developed  a 
tutorial  program  on  ADA  and  its  programming 
environment.  Tho  tutorial,  called  ADA2, 
was  developed  os  a  team  effort.  It  consists 
of  a  single  packngo,  consisting  of  three 
procedures.  It  is  fully  interactive  and 
was  written  to  run  on  the  university's 
Amhdal  470  V/8  running  IBM  VM/SP  release  5. 
The  Amhdal  470  v/8  is  architecturally 
equivalent  to  the  IBM  370.  The  compiler 
used  in  developing  this  project  was 
Telesoft's  Tolegon2  ADA  development  system 
for  the  370  —  A370  version  1.0. 

Briefly,  tho  operation  of  this  program 
is  as  follows.  Tho  prinary  procedure 
called  procedure  Menu  is  responsible  for 
displaying  the  main  menu  which  consists  of 
the  topics  which  can  bo  chosen  by  the  user 
during  a  particular  session.  This 
procedure  also  controls  the  flow  of 
operations  during  a  tutorial  session.  The 
selection  of  topics  available  through 
procedure  Menu  in  ADA2  is  as  follows: 


of  Mississippi 

RESPONSE  TOPIC  OF  INTEREST 


0  Table  of  Contents 

1  Introduction 

2  Runtime  Environment 

3  Subprograms 

4  Packages 

5  Exceptions/Handlers 

6  Generics 

7  Tasks 

8  Tasks  (in  brief) 

9  Quit 

The  user  enters  a  response  and  the  file 
corresponding  to  this  response  is  passed  to 
procedure  Topic.  Procedure  Topic  then 
reads  the  information  in  this  file  and 
displays  it  on  tho  screen,  filling  the 
screen  with  each  display.  The  user  may 
either  quit  at  this  point  or  continue  tho 
tutorial.  When  all  of  the  information  in 
the  Topic  file  has  been  displayed,  the  user 
is  queried  as  to  whether  or  not  he  would 
like  to  test  his  knowledge  by  being  asked 
a  series  questions  concerning  it.  If  the 
user  responds  yes,  Procedure  Topic  calls 
Procedure  Runexcr  which  allows  the  user  the 
opportunity  to  respond  to  a  series  of  true 
and  false  questions  about  the  material. 
Once  the  user  has  finished  testing  his 
knowledge,  or  if  he  determined  not  to  do 
so,  he  is  returned  to  the  menu  of 
selections  (Procedure  Menu) once  again. 


(II)  A  DISCUSSION  OF  HOW  THE  ADA  LANGUAGE 
WAS  USED  WITHIN  THE  CONTEXT  OF  THE 
ADA2  PROJECT  TO  UPHOLD  THE  GOALS  AND 
PRINCIPLES  OF  SOFTWARE  ENGINEERING. 

With  the  ADA2  project  in  mind  it  is 
important  to  determine  the  way  in  which  ADA 
was  used  during  the  development  of  the 
project  to  uphold  the  four  basic  goals  of 
contemporary  software  engineering 
practices.  According  to  Booch,  the  four 
basic  goals  of  software  engineering  are: 
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(1)  Modifiability, 

(2)  Efficiency, 

(3)  Reliability,  and 

(4)  Understandability.  1 

Modifiability  refers  to  the  ability  to 
control  the  impact  of  changoa  in  a  software 
product;  whereas,  efficiency  refers  to  the 
optimality  with  which  a  computer  system 
uses  its  available  resources  especially 
time  and  space.  Reliability  refers  to  the 
degree  to  which  a  system  is  failuro  free 
and  its  ability  to  degrade  and  recover 
gracefully.  Finally,  understandability 
refers  to  the  degreo  to  which  various 
people  who  examine  the  project  can 
comprehend  it  and  the  degreo  to  which  they 
can  isolate  the  objects  and  operations  in 
the  solution.  The  principles  which  ADA 
was  designed  to  support  which  lead  to  these 
goals  are  the  following: 

(1)  Abstraction, 

(2)  Information  Hiding, 

(3)  Modularity, 

(4)  Localization, 

(5)  Uniformity, 

(6)  Completeness,  and 

(7)  Confirmability.  1 

The  first  principle,  abstraction, 
refers  to  the  extraction  of  essential 
details  of  a  given  level  of  representation. 
The  second  principle,  information  hiding, 
makes  inaccessible  certain  details  which 
are  not  necessary  for  the  proper 
functioning  of  tho  rest  of  the  system. 
Both  abstraction  and  information  hiding  aid 
in  the  maintainability  and 
understandability  of  software  by  reducing 
the  amount  of  details  a  developer  nust  know 
at  a  certain  lovol  of  representation.  In 
addition,  the  reliability  of  software  is 
enhanced  when,  at  each  level  of 
abstraction,  only  those  operations  which  do 
not  violate  tho  logical  view  at  that  lovol 
are  available.  Modularity,  which  is  tho 
third  principle,  is  tho  grouping  of 
functions  or  operations  into  nodules 
according  to  some  criteria.  Localization, 
the  fourth  principle,  is  a  principle  aiding 
in  the  creation  of  modules  with  loose 
coupling,  that  is,  modules  that  are  highly 
independent,  and  in  the  creation  of  modules 
having  strong  cohesion,  a  quality  exhibited 
when  all  the  inner  elements  of  a  modulo  are 
closely  related.  Both  modularity  and 
localization  support  the  software 
engineering  goals  of  modifiability, 
reliability,  and  understandability.  This 
is  because  if  a  system  is  structured  well, 
tho  ability  to  understand  any  given  module 
should  be  enhanced,  and  since  design 
decisions  have  been  localized,  the  effects 
of  modification  to  a  module  or  modules  will 
be  limited.  Also,  if  code  is  modularized 
well,  then  interconnections  among  modules 
will  be  limited,  thus  serving  to  enhance 


reliability.  The  fifth  principle, 
uniformity,  supports  the  software 
engineering  goal  of  understandability  by 
ensuring  that  all  the  modules  use  a 
consistent  notation  and  do  not  have  any 
unnecessary  differences.  Tho  sixth 
principle,  completeness,  ensures  that  all 
the  important  elements  in  a  module  are 
presont.  The  seventh  principle, 
confirmability,  refors  to  the  ease  with 
which  a  system  can  be  tested  to  confirm 
whether  or  not  it  meets  requirements.  Both 
support  the  goals  of  reliability, 
efficiency,  and  modifiability  by  aiding  in 
the  development  of  correct  solutions/ 

Within  the  context  of  tho  ADA2 
project,  the  ADA  language  and  environment 
assisted  in  realizing  those  principles  in 
following  ways.  Tho  principle  of 
information  hiding  was  realized  in  our 
project  through  the  use  of  the  three 
procedures  mentioned  earlier.  Each 
procedure  communicated  to  tho  other  via  a 
well  defined  procedural  interface  with  only 
the  essential  information  available  for  its 
use.  In  realizing  the  principles  of 
abstraction  as  well  as  information  hiding, 
the  power  of  tho  language  was  not  fully 
exploited  as  can  be  seen  by  examining  the 
package  specification,  which  appears  below. 


WITH  TEXT  10,  SYSTEM; 

USE  TEXT  10,  SYSTEM; 

PACKAGE  ADA2  IS 

PROCEDURE  MENU; 

PROCEDURE  RUHEXER(FT:FILE_ TYPE) ; 
PROCEDURE  TOPIC (  FT  :  FILEJTYPE) ; 
END  ADA2; 


Appearing  in  the  package  specification 
are  some  unnecessary  details  about  the 
tutorial  mechanics.  Specifically,  since 
both  procedure  Topic  and  procedure  Runoxer 
arc  subordinate  to  procedure  Menu  (as  has 
beon  previously  described) ,  and  since  it 
would  be  unnecessary  for  any  user  to  know 
of  their  existence,  these  two  procedures 
rhould  have  been  embedded  within  procedure 
Menu  so  that  from  the  specification  level 
only  the  declaration  for  procedure  Menu 
would  be  visible.  In  this  way,  the 
principles  of  abstraction  and  information 
hiding  would  have  been  better  realized. 

The  principle  of  modularity  was 
realized  by  grouping  the  tutorial  package 
ADA2  into  three  separate  procedures 
according  to  the  following  criteria: 

(1)  the  operations  to  be  performed  in 
procedure  Menu  were  to  be  only  those 
associated  with  displaying  the  menu  of 
available  topics  to  the  screen.  This 
included  preparing  each  file  for  its 
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possible  selection  by  the  user  by 
performing  an  open  on  each.  This  also 
Included  querying  the  user  as  to  which 
selection  ho  would  like,  and  thon  passing 
the  information  tile  corresponding  to  his 
selection  to  procedure  Topic. 

(2)  The  operations  to  bo  performed 
in  procedure  Topic  were  to  bo  only  those 
associated  with  displaying  the  indorsation 
fro*  the  file  to  the  screen,  a  screen  full 
at  a  tiss,  until  the  end  of  the  file  was 
reached.  Once  that  had  beer,  accomplished, 

rocedure  Runcxer  was  called  if  the  user 

ndicatcd  that  he  wished  to  test  his 
knowledge  of  the  topic  he  had  just  viewed. 

(3)  The  operations  perforsed  in 
procedure  Runoxor  are  simply  those  required 
to  read  in  tho  tost  questions  for  the  user 
and  to  notify  him  of  the  status  each 
response.  Runoxor  also  provides  a  final 
test  score  for  the  user. 

The  nodules  are  not  os  loosely  coupled 
as  Might  be  hoped,  but  this  is  due  In  largo 
part  to  tho  nature  of  the  project.  For 
exapple,  both  procedure  Topic  and  procedure 
Runexer  depend  upon  tho  functioning  of 
procedure  Menu  to  obtain  and  pass  the 
user's  topic  choice.  In  addition,  all  of 
the  Modules  exhibit  a  large  degree  of 
cohesivoness  since  tho  operations  within 
then  are  directed  toward  achieving  a  common 
goal  (i.e.,  displaying  the  nenu  of  choices 
and  obtaining  tho  user's  topic  selection, 
etcetera) .  Furthermore,  the  nodules  are 
all  uniform  since  they  were  all  designed  in 
a  top  down  manner.  Thoy  are  all  conplete 
since  thoy  havo  within  then  all  of  the 
important  elements  necessary  to  perform  the 
desired  operations.  This  completeness  can 
be  confirmed  by  having  a  user  operate  the 
tutorial. 

Finally,  it  can  be  seen  that,  of  the 
seven  basic  design  principles  stated 
earlier,  some  are  upheld  to  a  greater 
degree  than  others.  Zt  can,  therefore,  be 
concluded  that  even  a  language  developed 
with  the  idea  of  supporting  the  software 
engineering  principles  can"ot  ensure  the 
perfect  application  of  these  principles. 
Though  ADA  has  tho  power  to  support  these 
goals,  any  language,  even  ADA,  can  only  be 
as  powerful  as  its  users  allow  it  to  be. 
That  is,  writers  of  software  must  still  be 
carefully  aware  of  software  engineering 
principles  and  violate  them  only  with  care 
and  only  when  no  other  solution  seems  to  be 
available. 

(Ill)  PROBLEMS  ASSOCIATED  WITH  THE  USE  OF 
ADA. 

Now  that  the  way  in  which  ADA  served 
to  support  the  software  engineering  goal!* 
through  tho  ADA2  tutorial  project  has  been 
discussed,  it  is  appropriate  to  consider 
some  of  the  pitfalls  which  the  AD7.2  project 
had  to  overcome  as  a  result  of  using  ADA  as 
the  development  language.  A  necessary 


function  for  the  smooth  operation  of  the 
tutorial  was  the  ability  to  clear  the 
screen  so  that  information  could  be 
displayed  a  screen  at  a  tine.  (It  is 
important  to  realise  that  this  project  was 
beiag  done  in  a  mainframe  environment  with 
minimal  support  for  external  devices. 
There  was  no  library  support  for  clear 
screon.)  Without  this  function,  the 
alternatives  were  either  to  output  the 
information  lino  by  line,  which  eventually 
results  in  a  screen  full  of  material  that 
has  already  boon  read  with  one  new  line  at 
a  time  appearing  at  the  bottom  or  to  use  a 
sorics  of  now_line's,  a  solution  which 
could  not  be  guaranteed  to  always 
completely  clear  tho  screen,  especially 
since  system  information  would  be  printed 
to  it  occasionally,  thus  throwing  off  the 
functioning  of  the  rest  of  the  output 
statements  designed  to  print  information 
to  the  screen.  It  was  assumed  that  the 
new  page  subprogram  provided  within  the  ADA 
environment  to  page  files  with  the  mode  of 
"out"  could  bo  used  to  page  the  screen,  but 
this  did  not  work.  This  presented  a 
dilemma.  After  attempting  and  failing  to 
bind  and  link  an  assembly  language  module 
with  tho  purpose  of  clearing  the  screen  to 
tho  tutorial  it  was  discovered  that  Pragma 
Interface  could  be  used  to  interface  a 
system  dependent  assembly  language 
procedure  which  could  be  called  at 
different  points  in  the  code  to  clear  the 
screen.  The  usa  of  this  assembly  language 
procedure  caused  tho  program  to  be  non¬ 
portable  to  installations  not  possessing 
this  feature,  a  problem  one  would  not  have 
expected  to  encounter  within  the  ADA 
environment.  It  should  be  pointed  out, 
howover,  that  since  the  arrival  of  the 
Alsys  ADA  compiler  at  the  University  of 
Mississippi  and  the  development  of 
subsequent  versions  of  tutorials  written 
in  ADA,  thin  problem  has  bean  solved. 

Another  problem  which  could  be  viewed 
as  a  pitfall  from  which  the  ADA2  project 
team  suffered  was  having  to  deal  with  the 
largo  amounts  of  spaca  and  time  it  took  to 
compile  and  execute  the  code  each  time  thin 
was  necessary.  Though  student  computer 
disk  space  allotments  are  generally  small, 
they  are  usually  sufficient  for  most 
projects  developed  using  other  languages, 
even  when  these  projects  require  thousands 
of  lines.  However,  even  for  a  modestly 
sized  ADA  program  of  a  fow  hundred  lines, 
temporary  disk  space  of  10  to  20  extra 
cylinders  would  nave  to  be  set  up  and 
programs  had  to  be  shifted  back  and  forth 
from  the  teaporary  space  to  a  student's 
permanent  space  between  log  on  and  log  off 
since  temporary  space  disappears  upon  log 
off.  Also,  if  there  was  eny  load  upon  the 
system  at  all  when  reconciling  and 
executing  the  ADA2  program,  it  was  not 
unusual  to  have  to  wait  from  thirty  minutes 
to  an  hour  to  r?ceive  the  results.  ,\n 
equivalent  sized  Pascal  program  would  ha-‘o 
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compiled  under  the  ease  system  load  In 
under  two  minutes. 

There  are  several  other  factors  which 
could  have  contributed  to  this  time 
inefficiency,  but  anythin?  approaching  this 
amount  of  inefficiency  is  generally  viewed 
as  being  unacceptable.  Vet  again,  since 
the  arrival  of  the  Alsys  compiler,  it  has 
been  reported  that  this  time  inefficiency 
has  disappeared  and  ADA  progress  on  the 
erdor  of  a  few  hundred  lines  typically  take 
only  a  few  ninutes.  at  sost,  to  return 
results. 


(IV)  CONCLUSION. 

In  conclusion,  since  sany  of  the 
probloss  experienced  with  the  ADA  language 
secs  to  have  disappeared  with  the 
introduction  of  the  Alsys  ADA  conpiler,  it 
leads  one  to  think  that  these  probless 
night  bo  duo,  in  sone  part,  to  the  Telegen2 
ADA  conpiler  Uii'es  which  the  ADA2  project 
teas  worked.  Furthermore,  because 
subsequent  student  teans  have  been  very 
successful  in  areas  whore  the  writers  of 
ADA2  failed  it  can  be  concluded  that  nany 
of  the  difficulties  which  were  thought  to 
be  Ada  related  wore  conpiler  related  and 
not  always  due  to  limitations  of  the 
language  itself.  Evan  so,  a  project  having 
experiences  such  as  these  would  tend  to 
cause  the  members  of  its  project  tean  to 
look  much  more  critically  at  a  language  and 
certainly  much  more  carefully  at  conpilers. 
Also,  as  has  bcon  previously  stated  and  as 
can  be  soon,  though  ADA  ha3  the  power  to 
support  the  goals  of  software  engineering, 
it  does  not  have  the  power  to  enforce  then. 
Therefore,  software  engineers  sust  not  look 
to  ADA  for  sone  sort  of  magical  panacea, 
instead  thoy  should  see  it  for  what  it  is: 
a  very  good  tool;  albeit,  still  a  tool, 
which  is  subject  to  the  limitations  of  its 
usarc. 


NOTES 
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AN  Ado  SYSTEM  FOR  THE  PARALLEL  EXECUTION  OF  FP  PROGRAMS 


Norman  Graham 


Oklahoma  Slate  University 


Aksiiatt 

Tills  paper  describes  an  attempt  to  bring 
program  correctness  proof*  to  the  Ada  envi¬ 
ronment  by  providing  a  FP  to  Ada  translator 
and  «  run-time  system  for  FP  written  in  Ada. 
The  FP  run-time  system  uses  Ada  tasks  to  take 
advantage  of  the  small  grain  parallelism 
inherent  in  FP  programs.  A  tree  of  tasks  is 
generated  dynamically  to  compute  the  FP 
function  in  n  manner  that  is  based  on  graph 
reduction.  An  unexpected  discovery  is  that  Ada 
is  unable  to  kill  branches  in  this  task  tree  ns  it 
is  generated  currently.  To  circumvent  this 
problem,  the  run-time  system  is  prevented 
from  generating  branches  in  the  task  tree  until 
the  branch  is  known  to  bo  required. 


Mfllkflliflits 

Ada's  traditional  scope  of  applicability 
includes  real-time  systems,  scientific  pro¬ 
gramming,  database  systems,  and  distributed 
systems.  To  ensure  the  correct  building  of  these 
systems,  Ada  supports  and  promotes  the  use  of 
software  engineering  techniques.  These  tech¬ 
niques,  when  used  with  a  referential!)’  opaque 
language  such  as  Ada,  prevent  proving  that  a 
program  is  correct.  John  Backus  has  proposed  a 
functional  language,  FP,  that  is  refercnlinUy 
transparent  and  overcomes  this  limitation.1 
FP  1ms  an  associated  algebra  of  programs  that 
makes  it  possible  to  reason  about  programs  by 
using  the  laws  of  this  algebra.  John  Backus,  K. 
M.  George  and  G.  E.  Hedrick,  and  J.  II. 
Williams  have  provided  examples  of  program 
correctness  and  equivalence  proofs  using  this 


algebra  of  programs.1-5-8  One  goal  of  this  sys¬ 
tem  Is  to  provide  the  benefit  of  program  proofs  to 
portions  of  Ada  projects  that  nr*  originally 
written  in  FP,  and  then  automatically  trans¬ 
lated  to  Ada,  This  allows  Ada  programs  to  use 
subsystem*  that  have  been  proven  to  be  correct . 

Ada  also  provides  the  task  type  that  allows 
programmers  to  manage  explicit  parallelism 
in  their  programs.  Explicit  control  of  paral¬ 
lelism  becomes  extremely  difficult  when  there 
are  large  numbers  of  parallel  processes.  In 
contrast  to  the  explicit  parallelism  allowed  in 
Ada  programs,  functional  languages,  such  as 
FP,  contain  large  amounts  of  implicit  paral¬ 
lelism-parallelism  that  is  implied  by  the 
structure  of  expressions.  The  programmer  does 
not  control  this  parallelism,  and  thus,  is  not 
concerned  with  its  complexity.  The  second  goal 
of  this  system  is  to  provide  the  benefits  of 
parallel  program  execution  to  portions  of  Adc 
projects  that  are  written  originally  in  FP,  then 
translated  to  Ada  automatically.  This  is  done 
by  using  Ada  tasks  to  exploit  the  implicit 
parallelism  inherent  in  FP  programs. 


This  section  presents  an  overview  of  the  FP 
system  that  has  been  implemented  at 
Oklahoma  State  University.  It  is  similar  to  the 
FP  system  defined  by  Backus  in  his  Turing 
Award  Lecture.1  Most  of  the  differences  arc 
syntactic  and  were  motivated  by  a  desire  to  use 
tliis  system  with  ASCII  terminals.  The  FP 
system  is  composed  of: 

•  a  set  of  objects, 

•  n  set  of  primitive  functions  that  map  objects 
to  objects, 
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*  a  scl  of  functional  forms  Hint  produce  new 
functions  from  existing  functions, 

*  n  definition  facility  for  nnming  functions, 
And 

*  an  Application  operator  (denoted  by :)  that 
applies  functions  to  objects. 

QliktU 

An  object  is  one  of:  an  atom,  a  sequent'  <* 
objects,  or  undefined  (denoted  by  bottom).  Hn 
atom  is  one  of:  an  integer,  a  boolean  value 
(denoted  by  r  or  F),  or  the  empty  sequence 
(denoted  by  BMP?*).  A  sequence  of  objects  is 
denoted  by  .v0>  where  each  xt  is  an 
object.  The  empty  sequence  is  also  a  sequence. 

Primitive  Functions 

The  following  primitive  functions  are  defined 
in  this  FP  system.  The  funcliuns  are  given  on 
the  left  with  their  mennings  on  the  right.  (The 
symbol  1  is  read  bottom  and  $  is  read  empty). 

i:x»x  =  <x,„. St  l  St Sn -lx,  ;X 

length  :x«x  a  <x„„. n  ;x  =  f  »><r;X 

null :x  a  x  a  $  ->  7* ;  x  *  ^ F ;  X 

id:*  tax 

hd:*K*=-.  <x,,,..prw>  &  n  fc  l->x,  ;X 

tl:x»x  =  <Xj>**>^; 

x  -  <Xj,...pfn>  &  n  it  2  ->  <x2,...rTA>  ;  X 

transtxaxa  -> 

X  =  <x„...,xN>  <y„...  jn> ;  X 

where  x,  a  <*«,...#„>  and  y}  =  <yu...Jnj>, 

1 5tS»,  l&j&tn. 

and  :x  a  x  =  <7',7’>  ->  T ; 

x  =  <T,F>  v  x  =  <F,T>  v  x  =  <F,F> 

->  F  ;1 

or  :x  n  X  =  <T,T>  v  x  =  <T,F>  v  x  =  <F,T>  ->  7’; 
x  =  <F,F>  -4  F  ;1 

not  :x  »  x  =  71  ->  F  pc  =  F  ->  7’  ;1 


It  :x  a  X  a  <y,z>  (t  y  <  x  ->  7* ; 

x  =  <y,z>  St  y  fe  x  ->  F  ;X 

lo :x  a x  =  <y,z>  St  y  £  x  ->  7* ; 

x  =  <y,z>  Sty  >  x  ->  F  ;X 

gt:x*xa<y,z>  &y>x->  7'; 

x  =  <y,z>  k  y  S  x  ->  F  ;X 

no  :x  a  x  a  <y.z>  &  y  2>  x  ->  7’ ; 

x  =  <y,:>  ft  y  <  x  ->  F  ;X 

eq :x  a  x  a  <y,t>  Sc.  y  =  x  ->  7’ ; 

x  a  «y,z>  &  y  *  x  ->  F  ;X 

no  :x  a  x  a  <y,z>  &  y  *  x  ->  7' ; 

x  =  <y,z>  St  y  *  x  -i  F  ;X 

add:*  « x  =  <y,z>  & y,  z  are  numbers  -> y+z  ;  X 

sub  :x  «  x  s  <y,z>  Sty,z  are  numbers  ->  y-z  ;  X 

mul  :x  "  x  =  <y,z>  St  y,  z  are  numbers  -►  yxz  ;  1 

div  :x  a  x  -  <y,z>  & y,  z  are  numbers  &z* 0 
->yz :  X 

Functional  Forms 

The  functional  forms  arc  actually  second- 
order  functions  that  accepL  functions  (or  objects 
in  the  case  of  constant)  ns  arguments  and 
produce  a  new  function  ns  the  '.esuil.  The  fol¬ 
lowing  functional  forms  are  provided  by  this 
FI*  system. 

Composition 

(/"compose#)  :x*f :  (#:x  ) 

Construction 

l/ji— 1/»)  :x  ■  lf\  s*i— /»>*■' 

Condition 

lp->f:g)  :x  a  (jnx)  =  T-*  f:x  ; 

( /;:x)  =  F->#:x  ;X 

Constant 

(constant  0)  :x*x  =  X  -»  X;  0 
where  0  is  any  object. 


7th  Annual  National  Conference  on  Ada  Technology  1989  177 


Insert 

/f:xax  =  <*,>  ->  a, ; 

a-  =  St  n  £  2 

A  ^(i/f •  ■!■ 

Apply  to  nil 

alpha  ftx  ux  = 

a  =  <t|,...^r),> 

->  ;1 

Function  Definition 

In  this  FP  system,  function  definition  is  of 
the  form 

Dot  /mmc  ■  (xfir, 

where  name  is  nn  alpha-numeric  string  nntl 
expr  is  n  function  expression  possibly  contain¬ 
ing  primitive  functions,  denned  functions, 
nnd  functionnl  forms.  For  example,  one  deft* 
nilion  of  the  factorial  function  is: 

Oof  sum  »  ?ul>  coopoae  |ld,  consume  1] 
l.'tf f  COO  *  eq  eospose  (Id.  constant  0) 

Dot  FACT  »  ECO  ->  constant  1; 

nut  conposo  |ld,  FACT  conposo  SUD1 | 

After  these  definitions  have  been  provided,  the 
application  of  the  factorial  function  FACT:  5 
will  yield  120. 

An  Overview.  of-Ada  ..Tasks 

This  section  describes  the  Ada  tasking 
facilities  used  by  the  FP  run-time  system. 
Further  details  on  Ada  tasks  can  be  found  in 
several  books.4-6 

In  Ada,  the  task  type  is  provided  to  give 
programmers  explicit  control  over  the  concur¬ 
rent  execution  of  programs.  Each  task  is  pre¬ 
sumed  to  be  executed  on  a  logical  processor  of 
its  own.  These  logical  processors  execute  their 
tasks  independently  except  at  points  where  two 
tasks  synchronize.  In  Ada,  this  synchroniza¬ 
tion  is  called  a  rendezvous  and  it  occurs  when 
one  task  calls  an  entry  in  a  second  task,  nnd 
the  second  task  accepts  the  call. 

As  one  of  the  four  forms  of  program  units 
(the  others  are  subprograms,  package,  nnd 
generic  units),  the  task  unit  contains  a  task 
specification  and  a  task  body.  The  task 


specification  defines  the  entries  (if  any)  for  the 
task.  The  task  body  defines  the  executable  por¬ 
tion  of  tasks  of  the  type  being  defined. 

As  n  limited  type,  a  task  type  may  be  desig¬ 
nated  by  the  definition  of  an  access  type.  This 
allows  the  dynamic  creation  of  tasks,  each  with 
its  own  logical  processor,  by  the  evaluation  of 
nn  allocator.  11  is  important  to  note  that  the 
master  of  n  task  allocated  in  this  way  is  not 
necessarily  the  unit  that  created  (he  task.  The 
master  of  a  task  allocated  in  Uiis  way  is  the 
unit  that  elaborated  the  definition  of  the  access 
type,  'litis  has  important  implications  ns  to  the 
unit  that  is  able  to  terminate  a  task  nnd  its 
stave  tasks. 

Synchronization  nnd  communication 
between  tasks  is  accomplished  by  the  ren¬ 
dezvous.  As  stated  earlier,  this  occurs  when 
one  task  calls  nn  entry  in  a  second  task,  nnd 
the  second  task  reaches  r-'t  accept  statement  for 
llint  entry.  As  nn  cxnmple  of  this  consider  the 
following. 

cask  A  ia 

entry  Blockln  (P:in  Block); 

end  A; 

tank  body  A  ia 

—  declarations 

begin 

—  do  something 

accopt  UlockXn  (P:  in  Block)  do 
—  decode  block 
end  Blockln; 

—  do  something  else 

end  A; 
task  0; 

task  body  B  is 

—  declarations 

begin 

—  do  some  stu ff 
A. Blockln  (P); 

—  do  some  more  stuff 

end  B; 

Here  we  have  task  B  calling  nn  entry  in  task 
A.  The  rendezvous  takes  place  when  task  B 
reaches  the  entry  call  nnd  task  A  reaches  the 
corresponding  accept  statement.  The  ren¬ 
dezvous  continues  until  A  has  decoded  the 
block  nnd  reaches  the  "end  Blockln"  state- 
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mcnl.  During  Ute  rendezvous,  task  B  is  sus¬ 
pended  and  does  not  resume  until  the  ren¬ 
dezvous  is  completed. 

Evaluation  Strategy  for  Fl>  Programs 
Brief  Introduction  to  Grauh  Reduction 

Graph  reduction  is  a  popular  method  used 
in  the  evaluation  of  functional  programs.3  To 
illustrate  this  technique,  consider  the  follow¬ 
ing  FP  program  and  its  evaluation  via  graph 
reduction. 

De£  £  -  [mul,  add) 

£:<5, 7> 


n) 


/  \ 

C  <5. 7> 


U)  5 

'  /  \ 

<5.7> 

nut  Atitl 


/  \ 


/  \ 


mul  <S,7>  »«Jtl  <5, 7> 


could  be  applied  from  led  to  right,  from  right  to 
left,  or  simultaneously.  This  property  is  the 
result  of  the  referential  transparency  of  FP 
programs  and  leads  to  their  parallel  execution. 

The  FP  Bun-time  Exflluatflr 

The  FP  run-time  system  exploits  the  paral¬ 
lelism  revealed  by  the  graph  structure  of  FP 
progiams.  As  an  example  of  this,  consider  the 
graph  of  the  FACT  function  defined  earlier  (see 
figure  2). 


e)  <35, 12> 

Figure  1 

Figure  1  shows  the  steps  that  are  performed 
by  a  graph  reduction  of  the  function  £.  In  step  a, 
the  function  is  applied  to  its  argument.  Step  b 
shows  the  expansion  of  £.  In  step  c,  Uie  argu¬ 
ment  has  propagated  down  to  the  leaf  functions. 
Step  d  shows  the  reduction  of  two  branches  in 
the  graph  and  step  e  shows  the  final  reduction 
to  the  function  result. 

This  simple  example  illustrates  the  graph 
structure  of  functional  programs  and  their 
evaluation  via  graph  reduction.  It  is  important 
to  notice  that  the  reduction  of  independent  sub¬ 
graphs  can  occur  in  any  order  without  chang¬ 
ing  the  result  of  the  computation.  The  reduc¬ 
tions  performed  in  moving  from  step  c  to  step  d 


This  graph  guides  the  run-time  system  in 
the  creation  of  a  tree  of  tasks  that  computes  Die 
desired  function.  To  start  the  process,  the  run¬ 
time  system  dynamically  allocates  a  task  nnd 
asks  it  to  apply  the  functional  expression  rooted 
in  Uie  condition  node  shown  at  the  top  of  figure  2 
to  the  object  of  the  compulation.  This  task,  nnd 
ench  new  task  that  corresponds  to  an  interior 
node  in  figure  2,  is  responsible  for  three 
actions: 

•  dynamically  allocating  tasks  to  compute 
its  subexpressions  (Uiis  corresponds  to  the 
function  expansion  shown  by  figure  lb), 

•  passing  arguments  to  these  new  tasks  (this 
corresponds  to  the  argument  propagation 
step  shown  by  figure  1c),  nnd 

•  collecting  the  results  from  these  new  tasks 
when  their  subexpressions  have  been  com¬ 
puted  (this  corresponds  to  the  reduction  step 
shown  by  figures  Id  nnd  le). 
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The  tasks  corresponding  to  leaf  nodes  in  figure 
2  directly  compute  their  result  and  return  it  to 
the  parent  task  in  a  reduction  step.  At  each 
reduction  step,  the  corresponding  task  becomes 
terminated  and  disappears  from  the  task  tree. 
As  reduction  continues  in  the  task  tree,  interior 
nodes  became  leaf  nodes  and  are  reduced.  This 
process  continues  until  only  the  root  node  of  the 
task  tree  survives.  At  this  point,  the  run-time 
system  retrieves  the  result  of  the  computation 
from  the  root  node  and  execution  is  complete. 

While  the  graph  in  figure  2  is  cyclic,  its 
corresponding  task  tree  is  always  ncyclic.  A 
partial  task  tree  corresponding  to  a  possible 
evaluation  sequence  for  the  FACT  graph  is 
shown  in  figure  3.  Some  of  the  branches  in  the 
task  tree  have  already  been  reduced. 


Of  the  functional  forms  in  this  FP  system, 
only  construction,  condition,  and  apply  to  nil 
hnvc  the  potential  to  execute  their  child  tasks  in 
parallel.  Unfortunately,  the  dynamic  task 
allocation  strategy  that  was  chosen  prevent  the 
run-lime  system  from  taking  advantage  of  the 
parallelism  inherent  in  the  condition  func¬ 
tional  form.  The  elaboration  of  the  access  type 
used  in  the  allocation  of  new  tasks  occurs  in  the 
package  specification  of  the  run-time  system. 
Thus  the  package  that  defines  the  run-time 
system  is  the  master  of  every  task  created.'* 


This  prevents  us  from  killing  one  of  the 
branches  in  the  task  tree  rooted  in  a  condi¬ 
tional  node  and  raises  the  possibility  of  a  run¬ 
away  task  branch.  To  execute  the  condition 
functional  form  in  parallel,  we  need  the  allo¬ 
cating  task  to  be  the  master  of  each  task  that  it 
allocates. 

Currently,  the  whole  problem  is  avoided  by 
simply  ignoring  the  parallelism  inherent  in 
the  condition  functional  form.  A  possible  solu¬ 
tion  is  to  place  a  new  access  type  definition  for 
our  task  type  in  each  task.  Allocating  tasks 
with  the  new  access  type  should  make  the  task 
dependencies  match  the  conceptual  task  tree 
and  nllow  Die  aborting  of  entire  branches  in  the 
task  tree. 

Translation  af  FP  to  Ada 

The  FP  to  Ada  translator  is  written  in  the  C 
programming  language  and  uses  a  Yncc  gen¬ 
erated  parser  and  a  Lex  generated  scanner. 
The  translator  generates  Ada  source  code  (hat 
builds  objects  nnd  FP  program  graphs  at  run¬ 
time.  Both  the  objects  and  program  graphs  are 
composed  of  nested  lists.  Each  node  in  the  list 
contains  a  tag  Hint  identifies  the  node's  type 
nnd  determines  the  node's  contents.  The 
translator  places  code  at  the  end  of  the  module 
Hint  applies  the  main  function  to  Uie  main 
object  nnd  collects  Hie  result. 

Project, Status  and  Future  Work 

As  it  is  implemented  now,  this  system  pro¬ 
vides  Hie  possibility  of  program  correctness 
nnd  equivalence  proofs  for  portions  of  Ada  pro¬ 
jects  originally  written  in  FP.  To  further  this 
goal,  this  system  needs  a  tighter  integration  of 
Ada  to  FP.  In  particular,  Ada  procedures 
should  be  able  to  construct  FP  objects  nnd  call 
FP  functions  directly  with  these  objects  ns 
parameters. 

The  system  automatically  takes  advantage 
of  the  implicit  parallelism  of  FP  programs  by 
executing  these  programs  in  parallel,  thus  pro¬ 
viding  a  potential  for  the  increase  of  execution 
speed  on  a  multi-processor  machine.  However, 
more  work  is  required  to  exploit  safely  the  par- 
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nllelism  of  the  condition  futtcilonnl  form. 
Other  possibilities  for  improvement  include  the 
development  of  code  optimization  vin  program 
transformation  and  the  development  of  a 
heuristic  algorithm  that  will  prevent  the  cre¬ 
ation  of  new  tasks  for  computationally  inex¬ 
pensive  functions.  These  improvements 
promise  to  improve  the  execution  efficiency  for 
FP  programs. 
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TRANSFERRING  FROM  RASCAL  OR  C  TO  ADA 


Jun  itkolu  4nJ  Sun*  KWcntc ct 
CcmftUr  ScUntt 

Untut  lily  o/iVelresl* 
Lincoln,  N«<W«d 


AnSTHAtTf 

Thb  paper  reports  on  n  preliminary  study  of  programmer* 
trained  in  Pascal  or  C  transferring  lo  Ad*.  W«  videotaped  sub¬ 
jects  who  spoke  aloud  m  they  wrote  their  first  Ad*  protrim.  We 
developed  a  model  of  programming  In  a  New  language  and  com* 
pared  our  observations  lo  lK<  model.  Ai  might  lx  expected,  w* 
observed  that  a  treat  deal  of  lime  U  spent  rc*<IIiic  documeniailon 
and  trying  lo  IramlaU  lire  Knowledge  gained  from  lire  documenta¬ 
tion  Into  woeKatile  code.  TKere  was  atm  a  great  deal  of  iteration 
of  activities,  an  initial  eolation  attempt*  failed  and  new  approaches 
were  tried.  We  found  that  subject*  had  little  difficulty  with  the 
syntax  of  Ada  or  with  the  semantic*  of  construct*  which  had  close 
counterpart*  In  their  Known  languages.  Trey  did  have  difficulties 
with  the  semantic*  of  uni-pre  construct*  and  with  developing  algo¬ 
rithm*  which  would  he  easy  to  Implement  In  Ada. 


INTRODUCTION 

The  transfer  of  shill  from  one  programming  language  to 
another  I*  near  transfer  because  It  involve*  transfer  between  two 
•Kill*  which  are  closely  related  to  each  other  .  The  opposite  of 
near  transfer  I*  far  transfer,  which  Involve*  l-jnifer  from  on*  iKtll 
or  Knowledge  domain  lo  another  far  afield  from  it.  Studying  near 
transfer  between  programming  language*  U  of  cegnitivt  Interest 
beesuse  St  I*  an  eatenslon  of  the  study  of  learnln*  to  program,  an 
area  U  which  much  recent  work  ka*  been  done1’'  .  In  addition, 
there  are  practical  reason*  for  Interest  in  ihill*  transfrr  In  program, 
mlng.  Programmer*  U  all  level*  front  student*  lo  professional*  are 
faced  with  the  task  of  learning  new  programming  languages,  often 
on  their  own  and  without  formal  Instruction.  The  current  situs- 
tlon  with  Ada  I*  a  good  example.  Ada  I*  aeUom  taught  In  nnivec* 
eky  computer  science  program*,  yet  It  at  widely  used  In  govern¬ 
ment  and  Industry.  Sometime*  programmer*  are  given  In-kous* 
training  In  Ada,  but  not  always,  and  the  training  course*  vary 
widely  In  their  length  and  content.  Whether  training  I*  given  or 
not,  there  I*  a  atrong  uaderlylng  assumption  that  programmer*  can 
fairly  easily  transfer  the  Knowledge  and  skill*  they  have  developed 
In  other  procedural  language*,  like  Pascal  and  C,  to  Ada.  Yet  our 
experience  teaching  course*  in  which  student  programmer*  have 
transferred  to  n  new  language  Independently  suggest  that  they 
encounter  gnat  difficulties.  Although  transferring  to  n  new 
language  Is  always  easier  than  learning  a  first  language,  it  is  still  a 
hard  lash. 

Although  there  St  no  existing  body  of  work  on  transfer  of 
skill*  between  programming  languages,  there  is  a  growing  body  of 
research  on  near  tranafer  in  tut  editing.  Much  recent  work  on 
transfer  of  skill*  between  tut  editor*  hu  been  based  on  a  common 
elements  theory  of  transfer,  Lt.,  the  Idea  that  knowledge  of  one  edi¬ 
tor  will  transfer  to  another  only  if  the  two  share  common  ele¬ 
ments  •  1  .  Taking  off  from  the  performance  theory  of  Card, 
Moran,  and  Newell  ,  the  common  element!  theory  hu  been  opera¬ 
tionalised  by  defining  the  task*  in  each  editor  by  Us  own  set  of 
production  rules.  Quantitative  predictions  of  transfer  time  can 
then  be  made  by  determining  the  number  of  new  production*  that 


must  b*  acquired  to  use  the  new  tdtv 

In  programming,  unlike  tut  editing,  quantitative  theories  of 
performance  and  learning,  which  would  be  applicable  to  transfer, 
do  not  currently  exist.  In  order  to  make  theoretical  progress  w* 
need  a  database  of  empirical  tvhlcnc*  about  what  transfer*  and 
how.  Our  purpose  In  this  study  was  to  observe  a  small  number  of 
programmer*  transferring  lo  Ada  and  use  these  observation*  lo 
create  a  model  of  lb*  activitie*  programmer*  engage  In  and  the 
strategies  they  use  In  transfer.  We  also  wanted  to  characterise  any 
special  difficulties  programmer*  seemed  to  face  In  beginning  to  use 
Ada.  Uecause  of  the  uploeatory  nature  of  the  Study  and  the  small 
number  of  subjects,  w»  did  not  Intend  to  do  any  statistical  ana. 
lyses  of  the  data. 


EXPERIMENTAL  METHOD 

For  this  Initial  study  w*  videotaped  two  programmer*  who 
normally  week  In  Pascal  or  C  u  lb«y  wrote  their  first  program  In 
Ada.  One  of  the  subject*  was  a  computer  rebate  graduate  atudent 
and  was  a  highly  experienced  and  skilled  student  programmer. 
The  Other  subject  had  worked  a*  n  professional  programmer  for 
three  year*  la  SASIC,  COBOL,  and  Pascal  Both  had  previously 
Warned  new  programming  language*  Independently  from  books  and 
manuals.  The  subject*  were  Instructed  to  speak  aloud  freely  at 
they  worked,  and  their  verbalisations  were  recorded.  They  wet* 
allowed  to  consult  documentation,  Including  an  Ada  textbook 
whenever  they  wished  .  The  subjects  were  allowed  a  maximum  of 
two  hours.  At  expected,  neither  of  them  finished  the  program  in 
that  time. 


Figure  1:  RJE  Probbm 

You  are  going  to  simulate  a  (simplified)  version  of  a  remote 
job  entry  facility  which  modifies  and  transmits  data  between 
two  computer*.  Your  program  will  do  three  thing*  to  rack 
tine  of  (ext  read  In: 

1.  Revere*  the  order  of  the  characters. 

2.  Translate  the  upper  case  character*  to  lower  case  and  vice 
vena. 

3.  If  a  line  is  less  than  CO  characters  long,  fill  It  with 
•'*  and  write  out  a  tine  of  length  <0.  If  a  line  Is 
greater  than  60,  writ*  It  out  as  separate  lines  of  exactly 

M,  filling  the  last  line  with  **s  if  necessary. _ 

The  probbm  used  In  this  experiment  appear*  In  Figure  I.  It 
is  a  text  processing  probbm  which  calls  for  a  series  of  operations, 
algorithms  for  which  would  be  familiar  lo  Intermediate  and  expert 
programmers.  The  solution  to  this  probbm  in  Ada  ha*  much  the 
same  outline  that  it  would  have  in  Pascal  or  C:  a  nested  loop 
approach  utilising  array*  of  character*  or  string*.  However,  an 
ideal  solution  In  Ada  terms  calls  for  using  some  features  unique  to 
Ada,  in  particular,  packages  for  I/O  and  attribute*  for  solving  the 
case  translation  subprobkm.  Other  Ada  feature*  which  might  be 
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Mt*d  but  an  Hot  accrue  ary  for  eolvkg  the  problem  ui  the  taKiab- 
■a((e«  of  variable©  wkaa  declared  and  tke  kelealUilon  ti  geaeric 
w«  thoeg  a  problem  which  did  aot  im  the  concurrency 
fiuttr*  of  Ada  beta  t«  »t  intruded  la  nee  ike  turn  problem  la 
Mudjr  Iraaefrc  la  other  progrv.imkg  Ua  ganger  which  da  not  tup- 
part  lamiwti1. 


MODEL  OP  nussrat 

Oar  propoeed  procedural  modal  for  Irudtr  between  pro- 
graauakg  language#  b  ehown  k  r  igert  2.  Tk«  modal  la  quite  gtn- 
aral  becauee  Ika  paocadart  art  amaU  expect  ika  peogrammer  la  fal¬ 
low  k  iruteferrkg  la  a  new  language  k  aal  tlrucluraUy  different 
from  Ika  procedure  ka  or  aka  would  follow  wkaa  writ  kg  a  program 
k  a  familiar  language.  Tka  mak  dUlkclloua  kalwaaa  wrUkg  k  a 
MW  language  aad  wri(k(  k  a  familiar  language  waald  ka  ika 
♦equate#  of  vnriout  tcltvitSet  aad  ika  aamkar  of  Iktaa  actrritbt 
ara  berated  k  carrying  oat  a  aaklioa, 

Oar  hypothaebed  modal  of  traaafar  behavior  Sa  bated  oa  tka 
Ida  a  ikai  program©  an  written  Sacramentally,  Oaa  expect#  ikal  a 
program  mar  vrbkg  a  program  k  a  laaguage  that  ka  or  tka  kaawa 
will  firrt  raad  ika  prokltm,  ikaa  patt  toma  tort  of  algorithmic  tola- 
Ika.  TV  it  will  mart,  likely  ka  a  language  kdapaadaal  kick  Wval 
plaa.  Depending  ©a  kow  familiar  ika  Individual  St  with  tka  pro- 
graauakg  language,  ka  or  tka  may  jo  immediately  la  UTiilkg  Ika 
coda  or  kata  ad  may  check  ika  programmkg  maaaal  for  apec'dic 
kformatSoa.  Oaa  expeclt  tkal  at  ika  program  mar  writ  at  Ika  coda 
ka  or  tka  may  atad  la  refer  la  Ika  maaaal  occatSoaaliy  la  ckaak  oa 
tack  thkge  at  tyalax,  ratarvad  arordt,  aad  a  vat  tern  antic©  of  con- 
ttracla  ad  frequently  atad.  If  ika  d receipt  ion  k  ika  kook  It 
uaebar,  Ika  programmer  may  look  for  aaamplta  k  ika  kook  or  k 
prtvSoatly  wrklaa  coda.  Afiar  ika  aoda  it  wrkUa,  maty  kdrvldu- 
alt  will  eh«k  Si  ky  kaad  to  Satan  ikai  wkal  St  wrklaa  Sa  comet, 
but  toma  will  Juet  allampt  to  compiia  aad  a  taenia  tka  <ad«.  After 
Ika  coda  St  laatad,  k  mart  ka  evaluated  to  tea  if  Si  St  k  error.  If 
Ika  coda  provat  lo  ka  kcorracl,  ika  programmar  will  tkkar  pota  a 
tolnlioa  lo  fit  U  or  raad  ika  docvmaatalSoa  toma  wort  Sf  ao  tola- 
tloa  It  InunadSalaly  okvtoat.  If  ao  arm  la  foaad,  ika  wkok  forego- 
kf  proem  will  ka  exact  lad  agak  lo  tolvc  ika  aaxt  tegmeal  of  ike 
proktem.  Tka  loop  k  Figure  2  win  ka  raaalarad  at  akkar  raad 
pftbkn  or  voKiilMa 


3a  rmt4dMl  n+u\ 


If  tka  programmer  it  uikg  an  unfamiliar  languaga,  we  axpecl 
tkal  Ike  number  of  iterationi  of  the  write  codt-rtad  book-look  for 
example  loop  would  b«  muck  kightr.  Tka  raad  book-pota 

tolutloa-wrile  coda  loop  would  alto  be  Ukaly  to  occur  wkk  a 
kSgkcr  frequency  at  tke  programmer  attempt!  to  implement  n  tolu- 
tion  k  tka  new  language.  If  tka  new  laagutge  it  quilt  different 
from  tkoaa  tkal  Ike  programmer  it  uted  to,  Ike  frequency  of  tkcae 
loop*  it  likely  to  be  in  created  more  than  if  tke  new  language  it 
timilar  lo  tkoao  tke  programmer  already  know*. 


OBSERVED  BEHAVIOR 

Fignn  3  below  akowc  tka  parranlaga  of  lima  aack  of  our  Ada 
eubjecta  tpaal  k  aack  activity.  Subject  I  wat  tka  graduate  rtn- 
deat  prorammer,  and  Subject  2  wat  tka  predate  ion  el  prorammar. 
la  tka  tart  column  wa  kave  included  for  cempirbcm  tka  Ikeat  for  n 
•ukjact  wko  Iranefeerad  from  Patcal  to  Icon.  Icon,  n  demandant  of 
SNOBOL,  It  muck  Sett  aimilar  lo  Patcal  tkaa  St  Ada,  no  iklt  Scon 
tukjacl  wUI  allow  ut  lo  make  tome  okaervatlooa  on  ika  effect  of  tka 
language  kekg  tranefarrad  lo  oa  tkt  Iraaeftr  procedure. 


Figure  3:  Dbtributkn  of  Solution  Tone  (percentage!) 
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Tka  two  Ada  aubjtcia  apant  a  comparable  amount  of  ika  k 
many  of  ika  actSvStlaa,  tuck  at  rand  problem,  pete  anketko,  Unk  hr 
ra  ample,  and  write  lode.  However,  I  key  differed  (really  k  tke 
amount  of  lime  that  ikey  a  peal  on  led  rode,  evaluate  tade,  and 
rand  Wnnk.  It  appeared  lo  ut  tkal  iklt  difference  wa a  ika  retail  of 
different  Searukg  Mylat.  Subject  I  wan  an  active  learner.  Ha 
immediately  began  to  write,  Inal,  need  debug  email  engmeale  of 
coda.  Ha  only  referred  lo  tke  documentation  wkee  ka  narked  an 
Impaine  and  kad  no  Una  of  kow  to  proceed.  Aa  noon  at  ka  tel 
eome  new  idea  from  Ika  documentation,  ka  began  Implemenlkg 
aad  lertkg  St  at  once.  Subject  2  wat  a  more  p  native  learner.  Ha 
waatad  lo  fiat  familiar  wkk  tka  languaga  before  Irykg  lo  run  even 
n  email  program,  and  ka  apant  a  good  deal  of  lima  ecaaakg  ika 
textbook  to  gain  an  overview.  Ha  apant  about  at  muck  lima  actu¬ 
ally  codkg  at  Subject  1,  but  ka  dU  not  let!  aad  evaluate  kb  coda 
at  ka  want.  Urtead  ka  want  on  lo  eokt  eucceaerve  eobpeoblama, 
earing  Ike  tertkg  for  Inter  (wklck  ka  never  rear  kad  became  liana 
ran  out). 

By  comparboo,  Iba  Icon  eubject  apant  latt  lima  wrkkg  coda, 
more  lima  poakg  aokllona  aad  more  lima  lookkg  for  enampbo. 
Skca  ka  wat  latt  familiar  wkk  ika  new  kkda  of  coetrtrucle  mad  k 
Icon,  ka  kad  lo  pota  many  eolation  plana  before  ka  aucceadad  k 
finding  one  ka  could  implement  k  Icon.  Ha  nleo  needed  lo  coaeok 
more  example!  lo  aaa  kow  ika  coaetrucU  akouU  be  coordkaled 
klo  a  program. 

CQMPARISQS  QP  THE  PROCEDURAL  MODELS 

Figure#  4  and  S  repretent  tka  bakavior  of  aubjecl  1  aad  2 
ratpadively,  k  graphical  farm.  Wkaa  wa  compart  thee#  two  fig. 
urea  wkk  tka  kypolkaabad  bakavioral  model  k  Figure  2  Ika  follow- 
kg  diffaraaect  ara  kdkalad.  Subject  2'e  bakavior  (pataka  learner) 
nora  clone ly  raaambba  tka  kypollMaitad  modal  except  Ikai  Subject 
2  did  aot  engage  k  Ika  lart-anda  aclivky,  and  kanca  tka 
kypolkaabad  loop#  kvolvkg  Ikb  aclivky  do  aot  appear  k  tka 
actual  bakavior.  A  loop  between  rand  problem-retd  book  appear* 
k  tka  bakavior  of  both  tubjecla  wk’tck  doea  aot  appear  k  our 
kypolkaabad  modal,  'tke  occurrence  of  Ikb  loop  migkt  be 
axplaked  by  tka  aubjeett'  poakg  aolulioaa  k  a  language  depen¬ 
dent  fatklon  rather  than  aUamptkg  (o  u aa  n  kigk  Wval  plan  and 
tkau  attempting  lo  implement  it  utiliikg  language  comlrucla. 
Tko  actual  problem  given  to  tka  aubjecta  wat  auck  tkat  tkt  prob¬ 
lem  apactficaiion  luggealtd  a  kigk  level  plan,  ao  aubjecta  did  not 
explicitly  atata  tkb  but  kalcad  attempted  to  generate  a  more 
localiied  algorithm  for  dtalkg  with  individual  poet  Iona  of  Ika  prob¬ 
lem.  The  pout  eolation  activity  for  Subject  2  wat  never  followed 
by  lookkg  for  an  example  although  it  wat  followed  by  rtadkg  tke 
book,  which  would  tuggett  tkat  kb  aolulion  wat  tpecific  eaough 
that  be  could  look  up  and  rend  nboul  conatructa  aad  aynlax 
needed  to  implement  it. 
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S«bJ»U  i'>  behavior  showed  mud  moet  Interaction  between 
the  vxr»»v  activities,  Mu tli  of  ikw  tin  b*  explained  by  hb  active 
learner  approach.  Hb  rtlutuce  10  read  uil  look  up  many  specif- 
ks,  relying  Instead  on  ’letting  the  computer  figure  k  out*,  gen¬ 
erated  more  it  (fit  ion  i  In  loops  and  mor*  paths  that  lk« 
hypothesised  model  did  not  peedkl.  TV*  path*  from  writ*  cod*  to 
ts*t  cod*,  from  t**t  cod*  to  nod  kook,  uni  from  rv*kt*U  (mb  to 
Uok  for  cumpke  tku  dkl  not  cxbl  in  lk«  hypothesised  behavior 
model  tan  bt  ru'Uy  explained  by  tk«  active  karncr  bthavioc.  The 
path*  from  mod  book  to  tvahsai*  tod*,  from  evaluate  tod*  to  rtod 
book,  from  trot  tod*  to  mod  bock,  uid  from  evaluate  rod*  to  writ* 
tod*  tkit  occur  in  on*  or  botk  subjects'  behavior  and  not  in  the 
model  cm  be  explained  by  tk*  subjects'  uafimiliartty  witk  tk* 
language.  One*  cod*  has  b**«  written  lk*y  need  to  co«lult  tk* 
book  to  om  if  tk*  cod*  appear*  to  Ik  corrtcl  uni  to  v*rify  tk* 
Mmantk*  of  tk*  encoded  construct*.  Tk*  utp*ri*nc<  level  of  tk* 
subject*  did  not  *«m  to  affect  tktir  behavior,  although  on*  would 
assume  tkb  might  not  b«  tk*  cm*  for  novic*  subjctls.  Tkb  point 
will  b«  Investigated  In  IU*r  rtudico, 

\Vk*n  w«  look  u  tk*  btkavior  mod*)  conitnicttd  from  tk* 
subject  writing  tk*  run*  problem  In  tk*  dissimilar  language,  Icon, 
on*  major  difference  U  apparent.  Figure  6  contain*  no  path  from 
read  bonk  to  writ*  tad*.  Sine*  tkc  language  being  used  la  thb 
cam  uses  dUa  rtructurc<  and  construct*  quite  different  from  tkoe* 
with  wkkb  tb«  subject  wu  familiar,  he  demonstrated  tk*  nted  to 
explicitly  Mate  kb  solution.  He  did  not  feel  tkat  kb  utua)  imple¬ 
mentation  plan  would  work  in  tkb  instance  and  tried  to  develop  a 
solution  more  in  keeping  witk  the  constructs  available  In  tbe 
language. 


.I’HQHUM?  ia  maaaauusg  tq  ini 

Ada  b  simitar  10  Otktf  procedural  programming  language*  In 
.most  ways,  so  major  difficult  l*<  writ  n«  expected.  Tkb  «n  eepe- 
elally  true  sine*  our  subjects  were  dealing  witk  n  simple  program¬ 
ming  problem  for  whkk  tkey  knew  appeopeiat*  algorithm*.  To 
som*  extent  tkb  proved  to  be  true.  I’arlkularly  witk  syntax,  few 
problems  surfaced,  and  those  wkkk  did  wee*  quickly  resolved.  For 
Instance,  snbject*  knew  (rum  bebf  Manning  of  ike  Ada  textbook 
tku  looping  etmewree  suck  an  wkite  and  for  loop*  existed.  Wken 
tkey  needed  10  actnally  net  tkeee  structure*  tkey  efficiently  looked 
up  detail  qneetloos,  for  example,  wku  b  ike  begin-* ad  equivalent 
in  Ada.  A  mocker  frequent  nppronck  to  revolving  eyntaetic  quee- 
tions  wa*  simply  to  cole  ike  construct  a*  It  would  b«  done  In  Pa*- 
ca)  or  C  and  let  ike  compiler  local*  mistake*.  One  sukject  took 
tkb  tppeoack  »ken  k*  wanted  to  find  out  wketker  array  subecript* 
of  0  Were  allowed  In  Ada.  He  fek  tku  It  would  be  farter  tkan  look¬ 
ing  It  np  In  ike  documentation,  and  it  probably  eu.  Tkc  few  syn¬ 
tactic  question*  wklck  peoveJ  to  be  a  tic  more  difficult  to  r**olv* 
Cam*  about  because  tkey  were  not  explicitly  answered  In  tkt  docu¬ 
mentation  For  example,  Snbject  I  got  an  error  message  wken  nehg 
*nd_of_fil*.  He  kypoikesbed  tku  ke  mlgkt  need  10  type 
**nd_of_rde*  in  all  uppercase  or  a  combination  of  Uppercase  and 
lowercase.  Tk*  question  was  not  nnew*r*d  in  ike  text,  and  tk* 
example*  need  wet*  ambiguous.  He  bad  to  experiment  witk  aU  of 
tkc  possibilities  before  concluding  tku  kb  mor  kad  notkixg  to  do 
witk  case. 

Semantic  problem*  wet*  generally  fairly  minor,  again  because 
Ada  b  similar  to  otker  procedural  language*  wkkk  ike  subject* 
knew  already.  However,  tksy  did  take  on  importance  wken  pro¬ 
gramming  constructs  in  Ada  kad  no  close  counterpart  In  otker 
known  languages.  Tkb  became  very  clear  In  our  observation*  of 
lb*  subjects  using  Ada  packages.  From  ovtrall  Manning  of  tkc 
Ada  textbook,  tk*  subjects  kad  an  Uca  of  wku  package*  were,  and 
tkey  qukkly  discovered  tku  tkey  bad  to  um  packages  for  1/0. 
However,  tkey  kad  trouble  actually  using  tkem.  On*  problem  wa* 
dbeovering  wkkk  package  to  um  for  I/O  and  figuring  out  wketker 
you  could  um  two  packages  at  one*.  Tkc  otker  problem  was  not 
understanding  exactly  wkat  operations  were  available  in  tbe  pack¬ 
ages  and  bow  tkey  worked.  For  example,  Subject  2  failed  to  dis¬ 
cover  tkc  Get  operation  and  kad  to  restructure  kb  original 
character-oriented  solution  approach  to  use  tk*  Cttlin*  instead. 
Subject  1  discovered  tbe  Cetlinc  but  bad  great  difficulty  using  it  to 
read  in  strings  because  ke  was  used  to  rtading  in  primitive  types  in 
Pascal  and  did  not  think  through  what  might  happen  in  reading  in 
structures. 

The  other  area  where  we  observed  transfer  probkm*  was  in 
planning  solutions.  The  problem  given  to  the  subjects  wa*  choMn 
so  that  subjects  would  know  algorithms  for  solving  it.  However, 
even  though  they  knew  algorithms  they  nevertheless  had  planning 
diflkultks.  The  trouble  was  that  tbe  algorithms  they  initially  pro¬ 
posed,  though  in  a  tense  language  independent,  were  based  on 
what  was  convenient  in  other  languages.  For  example,  in  solving 
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ik<  probkm  of  trantUtln*  uppercase  10  bwircve  ami  vke  v<m, 
S«l>}t<t  I  took  ike  approach  (wkkk  would  be  appropriate  in 

1’ **<*!)  of  addin*  or  rubtractln*  tbe  InUter  value*  of  correspond- 
In*  uppercase  xai  lowercase  ckvacters.  Ike  method  wkkk  k« 
tsrnd  tor  obtain!**  ik«  inte*er  value  gave  Mm  an  iile*al  type 
conversion  error  in  Alia  m4  forced  kirn  to  abandon  kb  algoeitbm. 
Subject  2  abo  ttbd  to  take  the  same  Pane  abide  approach  of  find- 
in*  a  function  that  would  five  a  numerical  vnlue  fee  x  character. 
Although  k<  scanned  tk<  t«j»tX«i  extensively  looking  tor  soene- 
iking  tkat  would  k<lp  him,  kb  search  of  the  Uat  was  directed  by 
what  ki  knew  of  PascaL  At  a.  result,  ke  persistently  looked  for 
functions  mi!  MW  to  look  at  ailfibnue,  wkkk  wguM  kart  solved 
kb  prokbm.  W*  discovered  many  limit  uhtb  observing  our  Sub¬ 
ject*  tkat,  whib  in  general  ibelr  expertise  »itb  another  language 
kilptJ  tktm,  h  abo  sometime#  knit  tk«Mt  »ke*  k  limited  tkt  solu¬ 
tion#  tkry  would  consider. 


COSCtHSIQN 

Prom  tkb  tmalj  sawpb  it  b  impossibb  to  draw  statistically 
rakJ  conclusion#.  However,  we  ran  note  tomt  Interesting  pWibilb 
lb«  to  watch  for  m4  tomt  additional  hypothesm  to  t«*l  an  wt  do 
onr  moot  Intensive  studies.  We  observed  difficulties  In  tkt  ability 
of  programmers  to  undefttMd  and  know  when  to  »a*  construct# 
wkkk  kad  no  dirttt  Malogb#  In  Iktb  ntnal  language.  Wt  abo 
observed  tkal  tktlr  plant  were  land  on  algorkhm#  tkat  tkry  kntw 
“On Id  kt  taty  to  Impbmtnl  In  Iktir  ntnal  language.  When  tkftt 
aktorkkmt  Inrntd  out  to  kt  atikwaid  to  Impbmenl  In  Ada,  tkt 
pri'*rnmm*f*  often  kad  difficulty  devising  natch er  nlgorichiu,  Tkb 
suggests  tkat  if  programtsssr*  tndereiotd  nw  construct#  better 
and  kad  greater  akUity  to  post  alternative  aktorkkmt,  lk<n  tkt 
it  tr at  ion  of  paikt  whkln  tkilr  Uhavior  graph*  wonld  decrease.  If 
tkb  doit  Indeed  Urn  onl  to  kt  tkt  <a*«,  k  wonld  uttot  tkat 
retrain!**  of  programmers  foot  on  aktorkkm  design  and  tkt 
ttmanlkt  of  unique  cMHrnctt  in  Ada,  bavin*  syntax  and  tkt 
remain  In*  trmantkt  tor  tkt  programmer#  to  dra)  wkk  on  tkilr 
own. 
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ABSTRACT: 

Pascal  is  often  used  as  a  reference 
point  when  approaching  the  Ada 
language.  when  a  program  developer 
used  this  procedural  approa*r.  to 
Ada,  ho  encountered  problems  of 
overloading  and  ambiguity.  After 
leasing  an  object  oriented  approach 
to  programming,  the  developer 
rehashed  some  of  his  design  and 
solved  his  problems.  His  opinion  Is 
that  the  procedural  (PASCAL) 
approach,  alone,  Is  lnsuflclent  when 
approaching  the  ada  language.  A 
knowledge  of  object-oriented 
programming  is  also  required. 


INTRODUCTION 

This  paper  Is  based  on  one  program 
developer's  experience  with  Ada.  It  Is 
not  intended  as  some  profound  conclusion 
to  years  of  research.  It  is  a  log  of 
what  happened  when  cue  program  developer 
chose  Ada  as  a  development  language. 
This  Is  where  the  significance  of  the 
paper  lies,  for  It  Is  the  program 
developer  who  must  use  the  language. 

DEVELOPER'S  BACKGROUND 

Since  the  Fall  of  1983,  the 
developer  has  been  a  member  of  a 
software  development  town.  Over  the 
years  he  has  developed  software  for  a 
variety  of  tasks.  Tnese  include  the 
development  of:  CAI  packages  for 
teaching  Ada;  graphic,*;  primitives  for 
use  with  a  microcomputer  based  PASCAL;  a 
specialized  data  presentation  tool  for 
use  with  a  mini-computer  based 
statistical  analysis  package;  and  tools 
for  automation  of  semi-repetitive  tasks 
and  documentation.  The  developer  also 
has  experience  in  developing  software 


for  non-computer  science  purposes.  He 
wrote  and  holp  design  a  computer  model 
of  the  contrast  sensitivity  of  retinal 
ganglion  cells.  The  developer  has 
experience  with  PASCAL,  FORTRAN, 
ASSEMBLY,  C,  C++,  and  ADA.  The 
developer  had  absolutely  no  experience 
in  object  oriented  programming. 

PROCEDURAL  (PASCAL)  APPROACH 

The  developer  was  faced  with  the 
task  of  writing  a  prototype  of  an 
authoring  tool.  He  decided  to  test  the 
Ada  language  on  such  a  task.  With  no 
formal  introduction  to  the  Ada  language 
or  object-oriented  programming,  the 
developer  used  a  procedural  (PASCAL) 
approach.  The  PASCAL  language  is  often 
used  as  a  reference  point  when 
approaching  Ada.  This  was  the  approach 
taken.  The  two  languages  are  similar  in 
structure  and  syntax;  similar,  but  not 
the  same.  This  was  the  source  of 
initial  problems.  Struggling  to  learn 
the  language  and  develop  in  it 
simultaneously  was  frustrating  at  first, 
but  once  the  developer  internalized  the 
style  of  Ada,  structure  and  syntax 
became  intuitive. 

The  major  problem  occurred  with  the 
use  of  packages.  When  the  developer 
tried  to  use  more  than  one  instantiation 
of  the  same  generic  package,  he 
encountered  overloading  and  ambiguity 
problems.  In  his  particular  case,  he 
used  more  than  one  file  of  the  same 
type.  Intuitively  he  expected  that  when 
a  read  or  write  operation  was  requested 
and  the  file  name  was  given,  that  the 
appropriate  file  information  would  be 
accessed.  This  was  not  always  the  case. 
In  some  instances  the  package  names  had 
to  be  provided.  At  the  time,  the 
developer  though  that  this  was  peculiar 
and  that  the  file  variable  should  be 
sufficient  to  determine  the  package. 

THE  OBJECT-ORIENTED  (C++)  APPROACH 

During  the  summer,  the  developer 
was  exposed  to  the  C++  language.  C++  is 
an  object-oriented  language.  The 
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lessons  learned  studying  this  Approach 
to  programing  would  prove  valuable. 
After  extensive  use  of  objects  with  this 
project,  the  developer  looked  at  thu 
design  of  the  authoring  tool  in 
retrospect.  In  redesigning  parts  of  the 
authoring  tool,  the  developer  avoided 
the  problems  of  overloading  and 
ambiguity  by  treating  each  file  as  an 
object. 

CONCLUSIONS 

The  developer  is  even  more 
impressed  with  the  Ada  language  after 
learning  an  object  oriented  approach. 
In  his  opinion,  Ada  is  an  excellent 
software  development  language.  Ada  is 
oriented  to  both  procedural  and  object- 
oriented  aspects  of  the  real  world. 
Also,  Ada's  support  for  data  with 
unknown  constraints  is  ideally  suited 
for  real-world  representation.  Neither 
PASCAL  nor  the  procedural  approach  alone 
are  a  sufficient  prelude  to  the  Ada 
language.  It  is  important  for  a 
developer  to  understand  object-oriented 
procramlng. 
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Ahrtrart 

In  Ada,  if  a  package  provide*  a  private  type 
(encapsulated  type),  it  mu«t  aUo  include  a  full 
declaration  of  the  representation  of  the  type  in  the 
private  part  of  the  package  interlace  syntax  (package 
specifications).  Potential  client*  of  a  package  are 
allowed  to  u*e  all  the  information  in  the  package 
interface  syntax  except  the  private  part.  Thi*  paper 
diieu«*e*  the  possible  roa*on*  for  including  the 
private  part  in  package  interface*.  The  claim  that 
the  private  part  facilitate*  the  compiler  of  a  client 
program  to  generate  efTicicnt  executable  code  i* 
analyzed  in  detail.  It  it  shown  that  the  private  part 
is  undesirable,  and  that  the  elimination  of  the 
private  part  need  not  retult  in  any  serious  execution 
inefficiency. 


Introduction 

Software  reusability  leads  to  two  distinct 
programmer  communities  —  the  developers  of  the 
reusable  software  and  the  clients  who  reuse  it.  (The 
developer  of  one  software  component  may  be  the 
client  of  another  component.)  This  dichotomy 
necessitate*  that  the  specifications  and 
implementations  of  reusable  software  components 
be  kept  separate.  The  specifications  serve  ns  a 
contract  between  the  developer  of  a  component  and 
the  clients. 

Ideally,  the  specifications  of  a  component 
should  precisely  state  what  Uie  component  does,  and 
nothing  more.  An  implementation  should  show 
how  the  specifications  arc  realized  in  a  particular 
way. 

The  specifications  should  provide  a  good 
abstraction  of  the  specified  concepts  by  exposing  all 
the  important  details.  Proper  abstraction  gives  the 
developer  the  flexibility  to  realize  the  specifications 


in  many  possible  ways,  and  exposes  to  a  potential 
client  exactly  what  should  be  known  to  use  the 
component,  without  having  to  be  concerned  about 
the  actual  implementation  details.  Specifications 
should  also  facilitate  information  hiding 5,  i.c.,  the 
specifications  should  reveal  no  more  than  what  is 
necessary.  The  principle  of  information  hiding 
complements  the  notion  of  abstraction.  If  the 
specifications  state  more  than  what  is  actually 
required,  the  developer  it  limited  in  what  can  be 
done  to  implement  the  specifications  and  the  client* 
are  overwhelmed  with  information  that  they  need 
not  know. 

The  separation  of  the  specifications  from 
implementations  provides  developmental 
independence,  essential  for  software  reusability, 
and  for  programming  in  the  large.  It  it  important 
that  modifications  to  an  implementation  or  a 
component  do  not  affect  the  clients  of  the  component 
(and  hence  the  client  components  need  not  be 
recompiled),  as  long  at  the  specifications  remain 
unchanged.  Actually,  many  possible 
implementations  with  different  performance 
characteristics  should  be  possible  for  the  same 
specifications,  and  the  clients  of  a  component  should 
have  the  flexibility  to  choose  an  implementation  that 
suits  their  performance  requirements.  Ideally,  a 
client  program  should  not  have  to  bo  recompiled 
even  if  it  changes  the  implementation  it  chooses  for 
a  particular  component, 

Ada  is  one  of  the  first  widcly-uced  languages  to 
support  the  notion  of  separate  component  interfaces 
and  implementations.  Typically,  an  Ada  package 
providing  an  abstract  data  type  declares  the  type  as  a 
(limited)  private  type,  and  provides  n  set  of 
operations  to  manipulate  variables  of  that  type. 
Every  package  has  two  separable  parts  —  a  package 
interface  syntax  and  a  package  body.  The  package 
interface  for  an  encapsulated  type  provides  the 
name  of  the  type,  and  the  interface  syntax  for  the 
operations  on  that  type.  In  addition,  it  includes  a 
private  part  which  shows  the  representation  used 
for  the  private  type  provided  by  the  package,  and  this 
is  the  topic  of  discussion  in  this  paper.  The  package 
interface  syntax  docs  not  formally  6tatc  what  the 
package  docs,  and  hence  should  not  be  called 
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•purification*.  However,  we  will  use  the  terms 
specifications  (Ada  terminology}  and  interface 
syntax  interchangeably  in  this  paper  when  there  is 
no  chance  for  confusion.  The  package  body  shows 
an  implementation  for  the  operations  listed  in  Use 
package  interface  syntax. 

This  paper  examines  closely  the  reasoning 
behind  the  inclusion  of  the  private  part  in  the 
interface  syntax  of  a  package,  and  shows  that  such 
inclusion  —  a  clear  violation  of  the  principla  of 
information  hiding  —  results  in  no  appreciable 
advantages. 


Whv  tln»  Private  Part  ? 

In  this  section,  we  critically  examine  the 
possible  reasons  for  including  the  private  parL 

The  Client  Programmer  Needs  H, 

The  private  part  of  a  package  interface  has 
been  termed  private,  because  it  is  not  intended  to  be 
visible  to  the  users  of  the  package. 

The  clients  of  an  Ada  package  are  not  allowed 
to  use  the  information  in  the  private  part  of  the 
package  interface  syntax.  In  fact,  clever 
environments  should  hide  the  private  part  from  the 
clients  of  a  package.  While  referring  to  the  private 
part,  Feldman4  notes  that  "unfortunately  Ada 
requires  that  the  data  structure  implementing  a 
data  type  appear  somewhere  in  the  specification 
part  of  a  package,  and  not  in  tho  'hiddon'  part  of  a 
package,  as  we  would  like  in  Uie  ideal"  and  that 
"Foj1  reasons  having  to  do  with  how  compilers  for 
the  language  will  be  implemented,  Ada  compels  us 
to  write  the  private  part  in  the  package  spccf/Icotion. 
Clearly,  it  would  be  preferable  to  hide  those  details 
away  in  the  body."  Obviously,  the  intention  of  the 
private  part  is  not  for  use  by  client  programmers. 

The  Compiler  Needs  It  to  Compile  Client 

If  some  part  of  the  package  interface  is  not  for 
use  by  potential  clients,  why  is  it  there  at  all? 

Apparently,  the  private  part  in  a  package 
interface  is  for  use  by  the  compiler  of  a  client 
program.  To  make  developmental  independence 
possible,  an  Ada  compiler  should  be  able  to  compile 
a  program  just  by  referring  to  the  interfaces  of  the 
packages  the  program  uses,  as  long  as  certain 
pragmas  (compiler  directives)  which  require  the 
compiler  to  refer  to  package  bodies  arc  not  used. 
(The  pragma  INLINE®  makes  the  compiler  expand 
procedure  calls  ia  line,  and  this  will  require  looking 
at  package  bodies.) 

It  is  possible  that  tho  private  part  shows  the 
representation  of  the  private  type  as  an  access 
(pointer)  to  a  data  structure  that  has  not  been  shown 
in  the  package  interface,  ana  instead,  has  been 


elaborated  in  tho  package  body.  In  this  case,  the 
compiler  of  a  client  program  essentially  has  the 
tame  information  that  it  would  have  in  the  absence 
of  the  private  part.  If  the  private  part  were  not 
specified,  then  the  compiler  can  automatically 
represent  a  variable  of  a  private  type  as  an  access  to 
an  arbitrary  data  structure,  and  tho  actual  data 
structure  can  be  filled  in  at  runtime3.  So  the 
compiler  can  generate  code  for  client  programs 
without  using  the  private  part. 

Hie  Compiler-Needs  It  to  Generate  Efficient  Code 

If  it  is  possible  to  compile  client  programs 
without  using  the  private  part,  then  live  reason  for 
the  private  part  must  arise  from  considerations  of 
execution  efficiency  of  client  programs3.  The  next 
section  explores  this  possibility  in  detail. 


Is  The  Private  Part  Needed  for  Oneratirn/  Efflckai 
Code? 

We  will  now  analyze  whether  the  claim  that  a 
compiler  can  use  the  private  part  to  generate 
efficient  executable  code  for  a  client  program  is 
really  true  by  considering  various  apparent  uses  of 
Uvo  private  part. 

Before  making  this  analysis,  however,  we  note 
that  even  if  this  is  a  valid  reason,  there  is  a  much 
bettor  solution  than  including  the  private  part  in  the 
package  interface  syntax.  Ada  can  introduce  a  new 
pragma  which  lets  a  compiler  refer  to  a  package 
body  for  the  actual  representation  cf  a  private  type. 
Since  Ada  already  includes  the  pragma  INLINE 
which,  lets  a  compiler  refer  to  a  package  body, 
inclusion  of  this  new  pragma  should  not  raise  any 
serious  objections.  This  new  pragma  can  be  used 
after  the  developmental  phase  is  complete. 

An  Example 

We  will  use  the  generic  'Boundcd_Stack' 
package*  shown  in  Figure  1  as  an  cxamplo  in  this 
discussion.  This  package  provides  an  abstract  dnta 
type  'Stack'.  A  representation  for  the  limited  private 
type  'Stack'  has  been  shown  in  the  private  part. 
Figure  2  shows  a  client  program  that  uses  this 
package.  'Int_Stack'  is  an  instantiation  of  the 
generic  'Bounded_Stack'  package  with  the  item  type 
'Integer'.  The  procedure  'client'  has  a  local  variable 
's'  of  type  'Int_Stack. Stack'. 

generic 

type  Item  is  private; 
package  Bour,ded_Stack  is 

type  Stack (size  :  Positive) 
is  limited  private; 

procedure  pop(s  :  in  out  Stack); 
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private 

typ*  Store  i«  array 

(Positive  rang*  <»  of  Icon; 

typa  Stack (size  :  Positive)  ia 
record 

top  :  Natural  :■  0; 
contents  :  Stored.. size); 
•nd  record; 
end  Bounocd  Stack; 


Figure  1  -  Interface  Syntax  for  the 
'Bounded^Stack'  Package 


declare 

package  Xnt  Stack  ia  new 

BoundecTstackdtem  «■>  Integer); 
uae  Int_Stack; 

procedure  client  ia 

s  :  Int_S tack. Stack (size  ■>  100); 
begin 

int_Stack.pop(s) ; 

•  •  • 

end  client; 


Figure  2  -  A  Client  Program  for  the 
' Bounded^ Stack 1  Package 


Direct  and  Indirect  Representations 

A  compiler  for  the  client  program  can  make 
u*e  of  the  information  in  the  private  part  of  the 
'Boundcd_Stack'  package  at  follows.  It  can 
represent  the  variable  V  directly  as  a  record 
containing  an  array  of  100  integers,  and  a  natural 
number.  In  the  absence  of  the  private  part,  the 
compiler  could  represent  ‘s'  indirectly  as  a  pointer 
to  a  data  structure  (since  the  actual  representation 
is  available  only  in  the  package  body),  this  data 
structure  to  be  filled  in  later.  The  inclusion  of  the 
private  part  in  the  package  interface  syntax  is 
because  that  there  might  be  a  slight  execution 
advantage  to  direct  representation. 

If  the  representations  of  private  types  are 
known  at  compile-time,  5c  is  possible  to  allocate 
storage  for  variables  of  these  types  statically. 
Otherwise,  the  storage  will  have  to  allocated 
dynamically.  However,  storage  has  to  be  allocated 
only  once  during  the  lifetime  of  a  variable,  and  this 
cost  may  be  amortized  over  the  many  operations  on 
that  variable.  Furthermore,  clever  dynamic 
memory  allocation  techniques  can  be  used  in 
reducing  this  overhead1.  Hence,  static  storage 
allocation  alone  cannot  result  in  any  appreciable 
execution  advantage.  There  is  a  possibility  for  some 
advantage  when  the  representations  are  accessed. 
Let  us  explore  this  possibility  further. 


Representations  of  Encapsulated  Types  Cannot 
Pe  Accessed  Directly:  Direct  representations  will 
save  an  extra  memory  reference  when  the 
representation  of  a  variable  can  be  accessed  without 
calling  a  procedure,  for  example,  if  the  procedure 
'client'  can  refer  to  's.top'  without  calling  any 
operations  on  'Stack'.  If  V  is  represented 
indirectly,  it  will  need  two  memory  accesses  to  refer 
to  's.top',  whereas  only  one  memory  access  is 
needed  if  's'  were  represented  directly.  But,  this  is 
not  possible  since  the  abstract  data  type  'Stack*  has 
been  encapsulated  as  a  private  type  in  an  Ada 
package,  and  hence  the  only  way  to  access  the 
representation  of  a  variable  of  that  type  is  by  calling 
one  of  the  operations  provided  by  the  package. 

In  Figure  2,  the  procedure  'client'  makes  a  call 
to  'pop',  one  of  the  operations  on  the  encapsulated 
type  'Stack*.  If  the  compiler  has  directly 
represented  the  variable  's'  (using  the  information 
in  the  private  part),  it  can  either  pass  a  pointer  to  's' 
or  can  pass  the  actual  representation.  Ada  leaves  it 
to  the  compiler  to  decide  on  what  is  passed6.  We  will 
discuss  both  cases. 

Parameter  Passing  bv  Reference:  In  our 
example,  it  is  much  more  expensive  to  pass  the 
actual  data  structure  than  a  pointer  to  it,  and  hence 
a  clever  compiler  will  only  pass  a  pointer  to  's',  even 
if  's'  is  represented  directly.  If  ‘s'  has  been 
represented  indirectly,  then  there  is  no  choice.  The 
pointer  is  passed  to  the  procedure  'pop'.  Thus, 
whether  's'  has  been  represented  directly  or 
indirectly,  what  is  passed  to  a  procedure  that 
operates  on  's'  is  a  pointer  to  the  data  structure 
representing  the  value  of  's'.  Thus,  there  is  no 
execution  advantage  to  direct  representation,  if 
parameters  are  passed  by  reference. 

Gannon  and  Zelkowitx3  conclude  from 
experimental  evidenca  that  "If  data  objects  have  to 
be  passed  (by  reference)  to  procedures  implementing 
abstract  operations  in  order  to  perform  the 
operation,  the  number  of  memory  references  in  the 
direct  and  indirect  implementations  is  likely  to  be 
similar."  Thoy  propose  that  the  compiler  expand 
the  procedure  calls  on  encapsulated  data  types  in 
line,  and  thus  eliminate  the  indirection  that  arises 
from  procedure  calls  even  when  direct 
representations  are  used.  However,  if  a  compiler 
has  to  expand  procedure  calls  in  line  (for  example, 
when  the  pragma  INLINE  has  been  used),  then  it 
must  refer  to  the  package  bodies  of  the 
corresponding  packages.  If  a  compiler  must  refer  to 
the  package  bodies  to  improve  the  execution 
efficiency  in  any  case,  then  there  is  no  need  to  make 
the  representations  of  private  types  available  to  the 
compiler  through  the  private  part  in  package 
interfaces. 

Parameter  Passing  by  .Yalue-Reault'-  If 
parameters  are  passed  by  value-result,  then  the 
representation  for  the  parameter  has  to  be  copied, 
and  this  takes  normally  time  proportional  to  the  size 
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of  the  representation.  Hence,  reference  parameter 
passing  is  usually  more  efficient  for  most  data 
structures.  However,  if  the  representation  of  an 
encapsulated  type  is  very  small  (e.g.  an  integer), 
then  its  representation  mightly  be  profitably  passed 
by  value.  (Ada  insists  that  parameters  of  scalar  and 
access  types  be  always  passed  by  value-result6.) 
This  would  be  possible,  only  if  the  compiler  knew  the 
representation  for  the  private  type. 

When  the  representation  is  indirect,  only  a 
pointer  can  be  passed  as  a  parameter.  However,  the 
called  procedure  can  dereference  this  pointer  at  the 
beginning,  and  can  use  the  dereferenced  address 
thereafter,  whenever  this  parameter  is  accessed. 
This  is  possible  since  the  called  procedure  knows  the 
actual  representation.  Dereferencing  takes  one 
memory  cycle  and,  such  dereferencing  is  necessary 
only  in  the  case  of  in  and  in  out  parameter  modes. 

We  conclude  that  whenever  the  representation 
of  a  private  type  is  comparable  in  size  to  that  of  a 
pointer,  and  an  operation  is  called  on  that  type, 
there  is  an  extra  memory  reference  if  the  private 
part  is  not  used.  But,  common  sense  and  experience 
would  argue  that  this  overhead  is  very  small  in 
actual  practice. 

Overheads  from  Access  Chocks:  One  of  the 
findings  of  Gannon  and  Zclkowitz3  is  that  when  an 
indirect  representation  is  used,  the  compiler  needs 
to  genrate  code  to  ensure  that  the  pointer  to  the 
accessed  data  representation  is  not  null.  Thoy 
report  that  this  overhead  from  indirect 
representation  is  negligible  when  a  pragma  to 
suppress  the  access  check  is  inserted. 

One  possible  solution  to  this  problem  is  to 
ensure  that  representations  of  variables  of  private 
types  are  neuer  null.  A  good  design  prnctico  is  to 
require  that  every  Ada  package  must  provide  two 
operations  "initialize"  and  "finalize"  for  each 
private  type  provided  by  the  package.  The 
"initialize"  operation  for  a  private  type  would 
allocate  storage  for  the  representation  of  a  variable 
of  the  type,  and  initialize  the  representation 
appropriately.  The  "finalize"  operation  would 
reclaim  the  storage.  In  our  example,  in  the  client 
program,  immediately  after  the  procedure  'client*  is 
called,  the  representation  of  the  local  variable  's' 
should  be  initialized  with  a  call  to  the  operation 
"initialize."  Similarly,  just  before  the  procedure 
finishes  execution,  the  storage  for  the 
representation  of 's'  could  be  reclaimed  with  a  call  to 
the  operation  "finalize."  These  operations  could  be 
invoked  automatically  by  compiler-generated  code 
whenever  a  variable  of  a  private  type  provided  by  the 
package  is  used.  The  language  should  establish 
these  rules,  and  eliminate  a  common  source  of  error 
in  programs  resulting  from  misuse  of  pointers. 


Why  Eliminate  thi>  Private  Part? 

Even  if  it  is  convincing  that  there  may  not  be 
any  significant  advantages  from  the  inclusion  of  the 
private  part  in  the  package  interface  syntax,  why  is 
it  any  harm?  This  section  <J;iscwssc*  the  many 
advantages  that  result  from  the  elimination  of  the 
private  part. 

Improved  Aha  traction 

While  considerations  for  a  certain 
implementation  may  usually  guide  tho  design  of 
specifications  to  some  extent,  it  is  unnecessary  to  let 
implementation  considerations  take  priority  over  the 
specifications  of  an  abstract  concept.  Having  to 
specify  the  private  part  in  the  package  interface  may 
overly  bias  the  interface  towards  a  particular 
implementation.  Such  an  approach  may  result  in 
interfaces  which  are  far  too  removed  from  the 
specified  concept,  and  too  close  to  an  actual 
implementation. 

It  is  also  conceivable  that  the  interface  syntax 
of  a  package  and  the  actual  implementations  may  be 
developed Try  different  people.  In  such  a  case,  it  is 
certainly  undesirable  to  let  the  specifier  do  part  of 
the  implementation2.  Implementation  decisions 
taken  too  early  may  turn  out  to  be  wrong. 

Bettcr.InfQrmaUon  Hiding 

The  principle  of  information  hiding  is  that  the 
specifications  should  expose  no  more  than  what  is 
necessary.  As  pointed  out  earlier,  over-specification 
restricts  the  choices  of  a  developer  in  implementing 
the  specifications,  and  overwhelms  a  client  with 
superficial  information  that  is  not  actually  needed  to 
use  the  component.  In  Ada,  the  private  part  in  a 
package  interface  exposes  more  than  what  is 
needed.  One  common  suggestion  that  is  advanced  to 
protect  the  clients  from  this  superficial  information 
in  Ada  package  interfaces  ia  to  build  clever 
environments  to  hide  the  private  part  from  the 
clients.  However,  this  suggestion  can  be  extended, 
and  it  can  be  argued  that  even  the  actual 
implementations  of  the  operations  could  be  listed 
with  the  operation  interfaces,  and  it  should  be  left  to 
the  environments  to  hide  the  implementations  from 
the  clients)  Such  an  approach  combines  the 
interfaces  and  implementations,  and  is  obviously 
undesirable. 

Imamed .Developmental  Independence 

The  specifications  of  a  package  are  like  an 
agreement  between  the  developer  of  the  package  and 
the  clients.  As  long  as  the  specifications  are 
unchanged,  the  developer  is  free  to  change  any 
actual  implementation  detail.  For  example,  in  Ada 
packages,  a  developer  can  change  the 
implementation  of  one  or  more  operations  provided 
by  a  package  by  changing  the  package  body,  without 
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affecting  clients  or  the  package.  That  it,  changes  in 
implementations  of  the  operations  provided  by  a 
package  do  not  result  in  recompilation  of  the  client 
programs  that  use  the  package.  However,  a  change 
in  the  representation  of  the  type  provided  by  a 
package  makes  the  developer  change  the  private 
part  in  the  package  interface,  and  thus  forces 
recompilation  of  the  client  programs  which  use  the 
package.  Recompilation  is  certainly  undesirable  in 
large  systems,  and  removing  the  private  part  will 
totally  eliminate  redundant  recompilation. 

Multiple  Implementations  for  the  Same 

Specifications 

If  the  specifications  do  not  expose 
representational  details  in  the  private  port,  then  it  is 
possible  to  implement  the  same  abstract  data  type  in 
many  different  ways.  For  example,  tho  abstract 
data  type  “bounded  stack"  could  bo  represented 
using  an  array  or  a  linked  list.  Since  in  Ada,  it  is 
possible  to  associate  only  one  package  body  with  a 
package  specification,  it  will  be  required  to  define 
two  packages  with  the  same  specifications  to 
support  two  different  implementations.  However,  it 
is  a  valuable  feature  if  a  language  supported 
multiple  realizations  for  the  same  specifications.  It 
is  possible  that  tho  inclusion  of  the  private  part  in 
the  package  interfaces  might  have  been  an 
important  reason  for  not  allowing  multiple 
implementations  in  Ada. 


foncluatora 

The  representation  of  a  private  typo  provided  by 
a  package  does  not  belong  in  Ada  package 
specifications,  and  the  private  part  which  shews 
this  representational  detail  is  unnecessary.  The 
private  port  violates  the  principles  of  abstraction  and 
information  hiding,  hinders  developmental 
independence,  and  docs  not  allow  the  possibility  of 
multiple  implementations  for  the  same 
specifications.  Elimination  of  the  private  part,  while 
solving  these  problems,  need  not  result  in  any 
serious  execution  inefficiency.  The  representation 
of  a  private  type  provided  by  a  package  belongs  in  tho 
package  body,  and  that  is  where  it  should  be. 
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ABSTRACT 

This  #  paper  examines  the  two 
languages,  Ada*  and  Smalltalk,  and  provides 
a  comparison  of  the  nature  of  the  object  in 
each.  Smalltalk's  only  data  structure  is 
tho  object  and  programming  is  a  matter  of 
message  sending  between  thorn.  Ada,  on  the 
other  hand,  is  an  ALGOL-like  block 
structured  language  which  supports  all  of 
the  simple  scaler  types  and  all  of  the 
structured  types  available  in  most 
block-structured  languages.  Tho  object  in 
Ada  is  in  torms  of  data  abstraction 
available  through  tho  Ada  package  and 
separate  compilation.  This  paper 
illustrates,  through  tho  use  of  simple 
little  procedures,  tho  difforoncos  in  tho 
two  approaches.  Finally,  through  a  careful 
evaluation  of  Smalltalk  it  trios  to  show 
what  is  meant  by  an  object-oriented 
language. 


The  object-oriented  style  has  often 
been  advocated  for  simulation  programs, 
system  programming,  graphics  and  AI 
programming.  Object-oriented  programming, 
or  sometimes  called  message-passing 
programming  views  data  as  objects.  An 
object  is  an  entity  which  combines  the 
properties  of  procedures  and  data  since 
both  perform  computations  and  save  the 
local  state.  Objects  respond  to  messages 
using  their  own  procedures  called  "methods" 
for  performing  operations.  An  important 
aspect  of  programming  used  by  message 
sending  is  Dada  Abstraction  which  means 
calling  programs  should  not  make 
assumptions  about  the  implementation  and 
internal  representation  of  data  types  that 
are  used  by  them.  There  purpose  here  is  to 
make  it  possible  to  change  underlying 
implementations  without  changing  tho 
calling  program. 

By  a  protocol  we  mean  messages  used  to 
define  a  uniform  interface  to  objects  which 
provide  a  particular  facility.  Additional 
leverage  is  provided  for  building  a  system 
when  the  protocol  is  standardized  which  is 
possible  because  of  polymorphism. 
Polymorphism  in  a  computer  system  refers  to 
the  capability  of  different  classes  of 


objects  to  respond  to  exactly  tho  same 
protocols. 

Inheritance  is  another  important 
concept  in  object-oriented  programming 
languages.  The  properties  which  allow  for 
inheritance  includo  methods,  class  and 
instance  variables.  Multiplo  inheritance 
is  the  ability  to  inherit  properties  from 
two  or  more  classes  and  the  accompanying 
semantics  are  an  area  of  current  rosearch. 

A  typical  object-oriented,  message¬ 
passing  language  will  view  data  as 
contained  in  objects.  Each  object  contains 
representation  information,  and  defines  the 
types  of  manipulation  that  may  be  performed 
upon  the  object.  This  implies  that  objects 
are  strongly  typed.  A  massage  which 
specifies  the  operation  and  the  operand  is 
sent  to  the  object.  Tho  object  then 
determines  whether  or  not  it  knows  the 
message  type.  If  it  docs  the  operation  io 
performed  and  the  object  if  required  is 
returned. 

The  object  model  is  an  abstraction 
mechanism  useful  for  understanding  the 
design  and  implementation  of  systems.  An 
object  is  either  active  or  passive. 
Passive  objects  are  program  variables  or 
databases.  An  active  object  is 
instantiated  in  a  program  or  procedure 
which  in  turn  transforms  or  acts  upon 
passive  objects.  Basically  an  object  is  an 
entity  that  combines  the  properties  of  data 
and  procedure  and  save  the  local  states. 

A  procedure-oriented  language  consists 
of  a  main  program  and  possible  calls  to 
subprograms  which  are  procedures  and 
functions.  Data  is  shared  by  subprograms 
through  several  techniques,  including 
passing  parameters  in  the  subprogram 
invocation.  The  basic  view  is  that  there 
is  data  and  there  are  procedures  that 
manipulate  the  data.  While  Ada  can  support 
object  oriented  design  because  of  its 
emphasis  on  data  abstraction  its  approach 
to  an  object  is  fundamentally  different. 

In  an  object-oriented  language,  each 
object  is  an  instance  type  which  refers  to 
a  class  or  and  instance  variable  or  a 
method  which  manipulates  an  object  or  a 
temporary  variable  which  issued  by  the 
instantiation  of  a  method.  Some  object- 
oriented  languages  permit  the  declaration 
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of  class  variables  which  are  shared  by 
objects  of  the  class  in  which  they  are 
defined. 

The  first  substantial  interactive, 
display- based  implementation  of  an  object- 
oriented  programming  language  was 
Smalltalk.  The  most  popular  version  of 
this  is  Smalltalk-80  licensed  by  Xerox. 

In  Small  talk  most  objects  ace  divided 
into  classes  and  instance  variables.  A 
class  is  a  description  of  one  or  more 
similar  objects.  -Instance"  Is  a  term  used 
to  describe  either  Che  relation  between  an 
object  and  its  classes  or  as  a  noun 
referring  to  objects  that  are  not  classes. 
Smalltalk  as  a  language  was  produced  as 
part  of  a  Dynabook  project  initiated  by 
Allen  Kay  in  the  Learning  Research  Croup  at 
Xerox  Palo  Alto  Research  Center. 

Smalltalk  is  implemented  by  passing  a 
message  to  an  object.  Each  expression  that 
is  evaluated  results  in  a  message  being 
sent  to  a  receiver.  The  receiver  which 
evaluates  the  message  selector,  determines 
the  method.  There  are  three  type  of 
message  selectors:  unary,  binary  and 

keyword.  In  Smalltalk,  and  object's  class 
determines  how  a  selector  is  to  be 
interpreted.  The  binary  messages  +,  -,  * 
and  /  may  take  on  different  meanings 
depending  upon  the  class  of  the  receiver. 
For  instance,  the  selector  +  can  be  used 
to  add  integers  or  perform  union  of  sets. 
The  interpretation  is  entirely  dependent 
upon  the  method  of  an  object.  This  might 
be  compared  to  overloading  an  operator  in 
Ada.  The  critical  difference  here  is  a 
binding  time  issue.  The  Smalltalk 
programming  environment  tries  to  provide 
every  tool  for  finding,  viewing,  writing 
and  running  the  methods.  Everything  is 
inside  a  window.  Every  program  is  just  a 
part  of  the  whole  system  that  is  linked 
together. 

In  Ada,  in  order  for  a  procedure  to 
call  a  variable,  the  name  declaration 
binding  has  to  be  specified  e.g.: 
x.getname(A) ; 

where  A  is  declared  as  a  character  earlier 
in  the  program  or 

x.getname(B) ; 

where  B  is  declared  as  an  integer  in  the 
declaration  section  of  the  code. 

This  kind  of  binding  is  called  static 
binding.  This  means  that  the  type  of  the 
argument,  that  is,  the  type  of  argument  A 
or  B  above  is  determined  when  procedure 
x.getname  is  compiled  with  argument  A  or  B. 
In  contrast,  in  object  oriented  languages, 
the  name  of  an  object  is  not  bound  to  a 
particular  class  until  runtime.  The  use  of 
methods  allows  an  operation  to  be  available 
for  the  instance  of  a  class  when  a  message 
is  sent  to  an  object  and  its  -type-  is 
bound  at  the  moment  of  the  message  passing 
and  not  before.  For  example: 

x:getname{A  or  B) 

means  to  get  A  or  B  the  message  getname, 


sent  to  an  object  of  class  x.  Sending  a 
message  is  very  similar  to  calling  a 
procedure.  The  difference  occurs  when  the 
message  is  received  by  the  'bject.  It  is 
the  object  that  decides  wh.s:.'  method  is  to 
be  executed.  This  occur?  *  thv  message 
is  sent  which  happens  whi**  the  program  is 
executing  hence  the  dynamic  binding. 

This  difference  i r<i  binding  is  the  most 
critical  difference  between  Ada  and  object 
oriented  programming  languages.  Of  course 
the  obvious  differences  of  compiled  code 
versus  interpreted  code  is  an  issue  but  it 
is  more  obvious  than  the  binding  time 
issue. 

The  similarity  of  the  two  languages 
lies  in  the  way  that  they  deal  with  data 
abstraction  or  the  ability  of  each  to 
encapsulate  an  object  and  its  particular 
attributes.  Ada,  through  its  package 
feature,  allows  the  user  to  write  and  use 
fully  encapsulated  object  descriptions 
giving  to  the  user  only  the  features  of  the 
object  which  the  user  is  required  to  have 
in  order  to  use  the  object.  Smalltalk 
likewise  is  able  to  fully  encapsulate  an 
object  and  to  allow  the  object  to  inherit 
from  other  classes  many  features.  It,  can 
limit  the  uoer's  view  of  the  object  through 
the  use  of  inheritance.  It  is  here  that 
the  comparison  ends.  Ada  is  a  completely 
procedural  language  designed  to  run  on  Von 
Neuman  machines  with  tasking  added  to  allow 
for  concurrency.  Smalltalk  has  a 
completely  different  design  philosophy.  In 
the  design  of  Smalltalk  the  basic  principle 
was  not  how  a  machine  worked  but  rather  how 
people  thought  about  solutions  to  problems. 
One  of  the  principle  design  goals  of  the 
authors  was  to  provide  an  easy  interface 
between  users  and  machines,  this  was  done 
with  objects  being  the  primary  basis  for 
the  interface.  Humans  naturally  solve 
problems  in  terms  of  objects  hence,  object 
oriented  languages  consider  the  object  and 
its  relation  to  objects  as  the  design 
issue.  It  is  this  issue  which  is  the 
motivating  force  in  software  engineering 
which  considers  itself  to  be  object- 
oriented.  The  design  process  is  object 
oriented,  the  programming  process,  in  non¬ 
object  oriented  lanquaqes,  is  not. 

Software  engineering,  like  object- 
oriented  programming,  requires  an 
environment  in  order  to  develop  large 
pieces  of  code.  Ada  does  not  provide  that 
environment  but  it  has  been  the  catalyst 
for  the  development  of  fully  integrated 
software  development  tools.  These  tools 
often  function  much  like  the  environment 
provided  by  many  object-oriented  languages 
but  the  programming  language  process  itself 
is  very  different  using  the  two  different 
languages. 
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To  graphically  Illustrate  the 
differences  between  tha  two  languages  let 
us  look  at  two  identical  programs,  one  in 
Ada  and  one  in  Smalltalk-80.  Tha  first 
example,  in  Ada,  is  taken  from  Gehani's 
book  Ad*. an . AdvAPg.td-Iatrg<lus6lgn  p-  M: 

»IiS  ItttJO;  u»«  IttiJO; 
pttttAiet  tMUjM_ua«l  It 

pKta««  IO_lM***r  It  rtw  lni«t«rJ9<lM(4tr); 

KtWr^tliliiitiuril; 

K*tWuri  k*ntl(«ia<tur*|;  t.t.U  OitfKltr)  It 

W«ln 

II  n  /•  0  (Mn 

ktn*l(ft,t,T,»; 

M(tm  kltk  *J;N«i)j 
rui(«lr«t  *);tvMi);nrt(  *«•*), •nrtHi: 

Htw.tlofJ 

»«!{«. l.i.r, i): 

kW  II; 
tnl  ml; 
b*iln 

fUII*»t«  M  Hill  km  I*  bt 
«IC»!2ir.OI.OltU>; 

tmtliMet/.oi.eltU.  **vtV**>: 

ml  iMit.ilJhial; 

A  program  which  accomplishes  the  exact  same 
thing  is  written  below  in  Smalltalk-80, 
this  code  is  taken  from  a  book  which 
contains  a  tutorial  for  Smalltalk-80  by  Ted 
Kaehler  and  Dave  Patterson  A  Taste  of 
SaalltalK  [p.7  or  p.  23] .  it  is  important 
to  realize  here  that  this  code  would  run  in 
the  "windowed"  environment  of  tha 
Smalltalk-80  system  so  that  it  is  not  so 
clearly  understandable  when  presented 
purely  as  code. 

Example: 

wvtTtmnlMliHt  fraa:fro*ln  ttsittln  utlr*:u«ln*l« 

ittixtlw  prottkri  It  mw  tk«  tltk  It  t  htIWit 
(rm  to*  kin  It  tntlhtr  pin  u»lo»  t  ililnd  pin" 

(KtlfOt  ►  OMUrutil 

Mil lr«Mlnltiuilnt'lnuiln«:ioPln. 
ttll  tonOlUilro^ln  loncPIn. 
ttlf  tovtloatrilktlpht  *1) 

lrot:utln*Pln  to: lot  In 
wlnc(rotPln) 

•onoltktfroein  ttnetin 

Hovt  dltk  (rot  t  pin  to  tnoth«r  pin.  Print  Iht  rotullt  In  lh« 
irmtcrlpt  window* 

Irmtcrlpt  cr. 

Irmtcrlpt  thow:((roi#ln  prlnt$trln*,'->',tePln  prlntstrlr*}. 

In  order  to  run  the  program  above  a  call 
statement  must  be  issued,  it  might  be  the 
following: 

(Object  rtw)  tovtlomriJ  (rotjl  toil  utlr*:  J. 

In  the  Smalltalk-80  program  above  the 
method  is  moveTower,  the  objects  are 
fromPin  and  toPin,  the  program  messages  are 
self  moveDisk  and  self  moveTower  where 
moveDisk  and  moveTower  are  messages  sent  to 
transcript  which  is  a  window  in  the  system 
browser.  Self  is  a  Smalltalk-80  reserved 
word.  The  flow  of  the  program  is  recursive 
in  the  same  sense  as  the  Ada  program,  it  is 
just  that  in  the  Ada  program  the  "objects" 
are  X,Y,Z  and  H  but  note  that  they  are 
actually  characters  and  numbers  where  in 


the  Smalltalk-80  program  the  objects  are 
simply  objects  and  it  is  not  really 
apparent  to  the  user  just  what  they  are. 
The  user  is  freed  from  the  process  of 
matching  some  non-disk  data  with  the  object 
of  interest,  in  this  case  disks  on  towers. 
So  that  true  data  abstraction  is  available 
in  the  Smalltalk-80  program  in  a  sense  in 
which  it  is  only  approximated  in  Ada. 

In  conclusion,  it  is  now  clear  that 
while  there  are  some  similarities  in  the 
two  programming  languages  the  differences 
are  vast  and  critical.  Smalltalk  is  a 
system  that  is  composed  of  objects  which 
can  be  executed  independently  and  in 
parallel  with  all  other  existing  objects, 
whore  the  objects  interact  with  one  another 
by  passing  and  receiving  messages. 
Therefore  the  concurrent  object-oriented 
approach  has  a  lot  in  common  with  tha 
process  model  in  Ada. 

Most  exeperlenced  programmers  will  have 
problems  learning  Smalltalk-80  or  other 
simlar  object-oriented  lengauges  because 
they  are  new  and  philosopically  so 
different  from  traditional  procedural 
programming  languages.  Perhaps  object- 
oriented  design  and  object-oriented 
programming  share  this  difficulty  in 
learning.  They  are  perhaps  too  close  to 
how  we  actually  think  for  us  to  see  how 
correct  they  are  for  designing  good 
computer  software. 
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t«n*  Vwn  Duo  U  <urr<nUy  *  J«nlH  In  Ow  etptriamt  tl  Caacuttr 
t<l«ncf  u  »h«  UnlvtruUr  *t  xltiltilffl*  *«  **fw<l»  U  r««ln  * 
•*>«Ur  «f  (ntlnnflnt  ul<*tt  In  iuy.  \Hf. 


Uwn  It  currently  »  Asiltr  In  »li«  e«ptrtwnt  *(  C<*cut<r 

Kltne«  tl  iht  UnlvtrtUy  tl  KlttlitlRil.  H  iipKIl  U  r«tlw  • 
ImMIk  •(  (nflnttrlny  Idcnct  In  >uy,  t*»0. 
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ABSTRACT 

Different  results  are  produced  when 
an  Ada  tasking  program  Is  re-executed 
with  the  same  Input  due  to  two  types 
of  nondeterminism.  This  problem 
exists  In  cyclic  debugging  of  Ada 
tasking  programs.  Nondeterminism 
reproduction  Is  difficult  In  Ada  due 
to  some  Ada  characteristics.  Our 
approach  uses  a  preprocessor  to  extend 
on  Ada  tasking  program  P  using  a  path 
specification  S  Into  P*  such  that  P* 
Is  a  deterministic  version  of  P.  P* 
can  then  be  re-executed  ns  many  times 
as  required  by  the  debugger  to  locate 
the  source  of  an  error.  Each  phase 
handles  a  different  type  of 
nondotermlnlsm.  Phase  One  creates  one 
Ada  task  controller  per  task.  Each 
controller  handles  thv  arrival 
sequence  of  entry  calls  tu  Its 
assigned  task.  Phase  Two  handles 
nondetcrmlnistlc  selections  by 
controlling  the  selection  of 
alternatives  within  selective  wait 
statements.  One  advantage  of  this 
approach  is  that  It  uses  more  than  one 
Aria  task  controller  for  the 
reproduction  process.  This  eliminates 
the  need  for  a  master  controller  which 
can  bo  a  bottleneck  to  a  solution.  The 
two  phases  are  easy  to  understand  and 
to  Implement. 


1.  INTRODUCTION 

There  are  basically  two  typos  of 
nondetormlnlsm  that  cause  Ada  tasking 
programs  to  produce  different  results 
for  tho  same  input  every  time  they 
are  executed.  Global  nondeterminism 
arises  as  a  result  of  the  relative 
progress  of  tasks  within  a  program, 
and  local  nondeterminism  arises  as  a 
result  of  an  explicit  choices  of  a 
nondeterministic  control  structure 
[10,  15].  Reproducing  the  same 
results  from  the  same  input  in  a 


language  that  supports  one  or  both  of 
these  types  Is  called  the  reproduction 
testing  problem  [4,  21].  Reproducing 
concurrent  programs  normally  requires 
the  reproduction  of  the  two  types  of 
nondetermintsm.  Global  nondeterminism 
Is  usually  more  difficult  to  reproduce 
than  local  nondeterminism.  This  is 
due  to  tho  fact  that  global 
nondotermlnlsm  is  difficult  to  record. 
Recording  an  execution  sequence  for 
Independent  events  In  different  tasks 
Is  an  example  of  recording  global 
nondotermlnlsm.  On  the  other  hand, 
local  nondeterminism  is  local  to  each 
task  and  can  easily  be  recorded  and 
replayed.  The  problem  exists  In 
cyclic  debugging  of  concurrent 
programs. 

Cyclic  debugging  Is  a  well  known 
process  for  debugging  sequential 
programs.  It  Is  used  to  locate  and 
remove  errors  after  they  have  been 
uncovered  by  a  test  case.  This 
process  is  well  understood  for 
sequential  programs  but  not  ns  well 
understood  for  concurrent  programs. 
The  snme  process  has  been  adopted  for 
concurrent  programs  [17].  Cyclic 
debugging  of  Ada  tasking  programs 
cannot  bo  nchlevcd  without  being  able 
to  reproduce  the  same  results  from  the 
snme  input.  Locating  and  removing  an 
error  usually  requires  more  than  one 
execution.  This  requires  finding  ways 
for  reproducing  the  two  types  of 
nondeterminism  mentioned  cnrllcr. 
Solutions  for  nondeterminism 
reproduction  arc  different  for 
different  languages  because  of  the 
characteristics  of  the  interprocess 
communications  and  to  the 
nondeterministic  control  constructs 
supported  by  a  language. 

Reproduction  of  global  nondeterminism 
for  an  Ada  program  is  reduced  in  this 
paper  to  the  reproduction  of 
rendezvous  (no  reproduction  is  done 
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for  shared  variables).  The 
reproduction  of  local  nondctermlnlsm 
1*  reduced  into  the  reproduction  of 
nondetermlnlstlc  selection*  within  nn 
Ada  task  due  to  a  selective  wait 
statement. 

Reproduction  of  a  rendezvous 
requires  that  the  two  partners  of  a 
rendezvous  to  natch.  In  languages 
that  support  the  symmetric  naming 
convention,  i.e.,  the  called  task 
knows  the  names  of  its  callers  and 
vise  versa,  a  construct  for  matching 
the  two  partners  of  a  rendezvous  is 
usually  built  into  these  languages  or 
done  automatically  [14].  Reproduction 
of  a  rendezvous  in  such  languages  is 
obviously  easier  than  in  those 
languages  that  adopt  the  asymmetric 
naming  convention  (the  called  task 
does  not  know  the  names  of  its 
callers).  We  expect  that  rendezvous 
reproduction  In  Ada  will  bo  difficult 
for  a  number  of  reasons:  Ada  adopts 
the  asymmetric  naming  convention,  Ada 
handles  entry  queues  in  strictly 
rirst-in  first-out  order,  and  Ada  does 
not  have  a  mutual  control  construct, 
i.e.,  accepting  an  entry  call 
according  to  some  value  of  its  passed 
parameters. 

A  solution  to  the  reproduction 
problem  for  Ada  transforms  an  Ada 
program  P  into  1”  such  that  the 
reproduction  of  the  same  results  of  P 
requires  one  execution  of  P'  with  nn 
additional  Input  of  a  rendezvous 
sequence  which  represents  the 
previous  execution  of  P  [21].  The 
solution  Is  based  on  the  reproduction 
of  a  rendezvous  sequence  using  a 
controller  that  controls  the  arrival 
of  entry  calls  to  the  called  task. 
Each  entry  call  must  first  call  a 
controller  and  Identify  Its  source 
and  destination;  then  the  controller 
returns  the  call  when  the  source  is 
the  other  partner  of  the  next 
rendezvous  In  the  destination  task. 
The  next  entry  call  to  the  next 
rendezvous  is  released  by  the 
controller  when  the  previous 
rendezvous  has  started.  One  drawback 
of  this  method  is  that  a  centralized 
controller,  which  can  be  a  bottleneck 
to  the  program,  Is  used. 

Some  approaches  for  debugging 
concurrent  programs  avoid  the  problem 
by  building  a  debugger  that  has  the 
ability  to  discover  and  locate  errors 


or  to  record  the  program’s  state  at 
each  stage  of  the  execution  [1,  9]. 

Another  approach  suggests  using  a 
new  programming  construct  called 
preference  control  to  control  the 
race  conditions  within  Ada  tasks  [8]. 
This  method  handles  only  local 
nondeterminism  and  does  not  force  a 
selection;  rather  it  suggests  one. 
Other  related  non-Ada  work  is 
presented  in  several  references  used 
for  this  paper  [1,17,18.20,22]. 

This  approach  basically  reproduces  a 
program's  rendezvous  sequence  by 
reproducing  all  task's  local 
rendezvous  sequences.  A  local 
rendezvous  sequence  is  associated 
with  a  task  in  nn  Ada  program.  This 
approach  is  partially  based  on  the 
theoretical  work  given  in  the 
following  references:  [2, 6, 7. 15, 16]. 
The  approach  suggests  reproducing  each 
local  rendezvous  sequence  independent 
of  the  other  local  rendezvous 
sequences  to  reproduce  an  original 
behavior  of  a  program. 

In  this  approach,  a  controller  Is 
used  to  simulate  a  communication 
environment  for  each  task  in  the 
original  execution.  The  selection  of  a 
recorded  sequence  of  nondetermlnlstlc 
decisions  a  task  has  taken  is 
enforced.  As  a  result,  a  task  behaves 
In  the  samo  way  it  did  In  the  original 
execution. 

The  approach  Is  divided  Into  two 
major  phases.  Phase  One,  which  handles 
global  nondctermlnlsm,  uses  an  Ada 
Task  Controller  (ATC)  per  task  to 
control  nn  arrival  sequence  of  entry 
calls  to  a  called  task.  It  Insures 
that  the  ordor  of  entry  calls  at  each 
entry '8  queue  Is  In  a  predetermined 
order.  The  second  phase,  which  handles 
local  nondctermlnlsm,  controls 
nondetermlnlstlc  selections  within 
individual  tasks.  This  Is  done  by 
using  a  set  of  conditions  to  disable 
or  enable  rendezvous  In  a  selective 
wait  statement.  Using  these  conditions 
one  can  enable  the  next  rendezvous  of 
a  rendezvous  sequence.  These  two 
phases  distinguish  between  the  two 
types  of  nondctermlnlsm  mentioned 
earlier  and  handle  each  type 
separately.  Note  that  each  of  these 
two  phases  requires  some  extensions  to 
the  Ada  source  program,  I.e.,  the 
addition  of  some  special  Ada  code  to 
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the  original  program.  This  extension 

©cos*  is  referred  to  as  extending  a 
rogrnm. 

One  Advantage  of  this  approach  is 
that  it  use*  one  or  more  ATCs.  One 
ATC  1*  assigned  to  control  entry 
call*  to  one  or  wore  tasks.  This 
simplifies  the  implementation  of  ATCs 
and  eliminates  the  need  for  a  master 
controller,  vhich  can  be  a  bottleneck 
to  a  solution. 

The  design  of  an  approach  that  can 
be  divided  lnro  two  smaller  phases  is 
another  advantage  of  this  approach. 
Each  phase  deals  with  a  problem  in  the 
reproduction  process,  but  the  two 
phases  work  together  to  achieve  the 
goal.  When  a  problem  is  spotted  at  the 
reproduction  process,  the  nature  of 
the  problem  guide*  us  to  the  phase  in 
Tault.  Other  advantage*  include  better 
understanding  of  the  reproduction 
process  and  ease  of  implementation. 

This  approach  limits  handling  of 
local  nondeterminism  constructs  by 
using  the  selective  wait  statement 
(the  other  type*  of  select  statement 
are  not  handled)  and  by  assuming  that 
no  rendezvous  nesting  occur*  in  it. 
The  COUNT  attribute  and  shared 
variables  are  also  not  hnndlcd.  An 
approach  for  handling  these  constructs 
is  given  in  reference  (21). 

A  discussion  of  problem  of 
reproducing  an  Ada  tasking  program 
and  what  special  Ada  characteristics 
may  influence  the  solution  is 
provided  in  Section  2.  Outlines  of 
the  reproduction  process  are  given  in 
Section  3.  Explanations  of  the  two 
phases  of  this  approach  are  presented 
in  Section  4.  A  complete  example  is 
given  in  Section  5,  and  conclusions 
are  presented  in  Section  6.  Appendices 
I  and  II  list  the  Ada  code  for  the 
example  given  in  Section  5. 


2.  REPRODUCING  ADA  TASKING  PROGRAMS 

In  languages  that  adopt  a  symmetric 
naming  convention,  rendezvous  can  be 
reproduced  easily;  the  two  partners  of 
a  rendezvous  automatically  match  in 
Communicating  Sequential  Processes 
(CSP)  [14].  In  CSP,  rendezvous  match 
through  an  Input  and  Output  commands: 
a  caller  issues  an  Output  command 
specifying  its  destination  task,  and 


the  called  task  l**ue*  an  Input 
command  specifying  it*  source  ta*k 
[14].  In  Ada.  rendezvous  are  more 
difficult  to  reproduce  because  an 
entry  in  a  destination  task  (a  called 
task)  should  rendezvous  with  the  first 
call  at  Its  queue  regardless  of  who  is 
calling  it,  and  each  entry  queue  is 
handled  in  strictly  flrst«in  first- 
out  order.  This  implies  that  a 
destination  task  cannot  determine 
where  each  call  originates.  If  the 
name  of  the  calling  task  (source 
task)  is  Included  as  an  entry  call 
parameter,  the  destination  task  does 
not  find  out  the  name  of  its  caller 
until  the  rendezvous  ha*  begun. 
Recause  Ada  does  not  have  a  mutual 
control  construct,  thi*  restriction 
cannot  be  avoided. 

A  mutual  control  construct  can  be 
useful  for  solving  the  problem  of 
mismatching  the  two  partner*  of  a 
rendezvous  in  Ada.  Such  a  solution 
require*  either  simulating  mutual 
control  by  the  exlsUng  Ada  constructs 
or  adding  such  a  construct  to  the 
language.  However,  a  mutual  control 
construct  is  not  needed  if  we  arc  able 
to  duplicate  every  entry  queue  ordor 
in  the  reproduction  execution.  This 
can  be  done  by  duplicating  (replying) 
the  original  arrival  sequence  of  entry 
calls  to  a  destination  task,  and  as  a 
result,  every  entry  queue  sequence  in 
a  the  destination  task  is  duplicated. 
This  approach  diminishes  the  need  for 
a  mutual  control  construct  for  the 
purpose  of  reproduction  of  rendezvous 
in  Ada.  Such  a  construct  will  still 
be  useful  for  explicit  scheduling  of 
Ada  tasks.  This  approach  adopts  the 
approach  of  duplicating  the  arrival 
sequence  of  entry  calls  to  a 
destination  task.  This  Is  done  by 
using  an  ATC  per  destination  task  to 
control  its  arrival  sequence  of  entry 
calls . 


3.  REPRODUCTION  PROCESS  OUTLINE 


Figure  1  presentD  the  general 
outline  of  the  approach.  A  path 
specification  is  a  net  of  local 
rendezvous  sequences  that  were 
recorded  in  a  previous  execution, 
usually  one  local  rendezvous  sequence 
per  task.  A  path  specification  file 
Is  a  file  that  contains  a  local 
rendezvous  sequence  for  each  non- 
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nailing  task  (<i  tftsk  with  at  leftist 
one  accept  statement  that  produced  a 
rendezvous*  In  the  origlnnl  execution). 
A  preprocessor  command  file  is  used  to 
specify  the  number  of  ATCs  that  will 
he  used  In  a  program  and  to  specify 
which  task  la  controlled  by  which 
controller.  An  Ada  source  program,  a 
path  specification  file,  and  a 
preprocessor  command  file  are  used  as 
inputs  to  a  preprocessor.  A 
preprocessor  Is  a  pregrnm  that 
extends  an  Ada  source  program  to 
accommodate  new  Ada  code  for 
reproduction.  The  new  added  code 
induces  the  number  of  ATCs  specified 
In  the  preprocessor  command  file  (ATCs 
are  explained  later  In  this  section). 

The  output  of  a  preprocessor  Is  an 
extended  Ada  program  that  has  the 
same  semantics  of  the  original  Ada 
program.  The  differences  are  the 
following:  the  extended  Ada  program 
Is  deterministic,  it  always  follows 
the  same  path  (specified  in  the  path 
specification  file),  and  it  gives  the 
same  results  for  the  same  input  every 
time  It  Is  executed.  When  the 
extended  Ada  program  Is  executed,  the 
results  of  its  execution  will  be 
compared  to  either  the  expected 
results  or  the  results  of  the 
original  execution.  Modifications  can 
then  be  made  to  the  original  Ada 
program,  If  desired,  and  the  whole 
process  can  bo  repeated  until  the 
desired  results  are  achieved. 

Definition  1: 

A  local  rendezvous  sequence  for  a 
task  T  Is  a  totally  ordered  sequence 
of  rendezvous  accepted  by  task  T  (T  Is 
the  destination  task),  where  each 
rendezvous  is  represented  as  a  three- 
entity  tuple: 

<  Rendezvous  sequence  number, 

Calling  task  Identity,  Entry  name  > 

A  rendezvous  sequence  number  Is 
unique  within  a  local  rendezvous 
sequence  of  task  T.  Note  chat  from 
this  definition  we  can  conclude  that 
a  task  with  one  or  more  accept 
statements  which  produces  no 
rendezvous  in  the  original  execution, 
or  one  with  no  accept  statements  at 
all  has  no  local  rendezvous  sequence. 
We  call  such  a  task  a  demanding  task. 


Flgu^a  1.  An  outline  of  this  approach. 

4.  TWO-PHASE  REPRODUCTION  FOR  ADA 
TASK  INK  PROGRAMS 


Two  phases  or  program  reproductlon- 
an  entry  cnlls  control  phnsc  nnd  a 
nondete minis  tic  selections  control 
phase  -  arc  discussed  In  this  section. 
The  extension  procedure  for  each  phase 
is  also  presented. 

The  first  phase  Is  to  use  one  Ada 
task  controller  per  task  (or  a  group 
of  tasks)  to  control  the  arrival 
sequence  of  entry  calls  for  that  task. 
An  ATC  assigns  n  unique  number,  called 
entry  call  sequence  number,  to  entry 
cnlls  that  are  calling  the  snme  entry. 
Entry  calls  can  then  be  accepted  In 
sequence  using  nn  entry  family 
approach,  provided  by  Ada,  nnd  a  loop 
with  an  entry  family  Index.  A  loop  Is 
used  only  If  no  loop  nlrendy  exists. 
This  phase  is  explained  in  more  detail 
in  subsection  4.1.  It  Is  assumed  here 
that  each  task  in  the  program  can  be 
uniquely  Identified.  The  advantage  of 
having  more  than  one  ATC  is 
significant  in  multiprocessor  systems. 
For  example,  having  one  ATC  for  each 
group  of  tasks  that  run  on  the  snme 
processor  reduces  the  amount  of 
communications  between  processors. 

The  second  phase  is  to  control 
nondeterministic  selections  Inside 
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TASK  K 


Ada  tasks.  This  Is  dene  by  extending 
each  task  T  Into  T*  such  that  the 
semantics  of  T  and  T*  are  the  same, 
basically,  each  task  keeps  track  of 
Its  local  rendezvous  sequence  and 
enables  only  the  rendezvous  at  the 
cop  of  Its  local  rendezvous  sequence 
and  disables  all  other  alternative 
rendezvous.  The  Index  to  the  local 
rendezvous  sequence  will  then  be 
updated,  and  the  process  will  be 
repeated  again  until  all  rendezvous 
occur.  The  entry  call  for  the  enabled 
rendezvous  Is  assumed  to  be  available 
from  the  first  phase.  If  It  Is  not, 
the  task  will  be  blocked  until  the 
appropriate  entry  call  arrives.  More 
details  are  given  in  subsection  4.2. 
These  tvo  phases  work  together  to 
achieve  the  reproduction  of  Ada 
tasking  programs. 

The  separation  between  the  two 
phases  or  the  approach  Is  necessary 
because  each  phase  solves  a  separate 
problem  In  the  reproduction  procoss. 
The  advantages  are  to  simplify  the 
implementation  of  the  two  phases  and 
to  make  each  phase  easier  to 
understand.  This  Is  especially  true 
at  the  stage  where  we  compare  the 
results  of  the  program  with  the 
results  of  Its  reproduction.  A 
failure  In  the  reproduction  of 
Interprocess  communications  most 
probably  points  to  a  failure  In  the 
entry  calls  control  phase. 

4.1  Entry  calls  control 

We  will  first  explain  Phase  One  in 
general  and  apply  it  to  one  entry. 
Later  In  this  section,  we  will  explain 
how  to  expand  It  to  include  more  than 
one  entry.  An  example  of  the  two 
phases  Is  given  In  section  flvo. 

Figure  2  shows  n  task  K  that 
contains  an  entry  WRITE.  It  also  shows 
that  there  are  three  entry  calls  to 
the  WRITE  entry:  x,  y,  and  z  (where  x 
is  at  the  top  of  the  entry’s  quoue). 
Note  that  In  this  figure,  we  are  using 
symbols  that  are  similar  to  the  one 
given  in  reference  [3].  Wo  are  also 
temporarily  using  the  calling's  task 
Identity  as  the  entry's  call  identity, 
i.c.,  we  are  using  the  letter  x  as  a 
task  name  and  as  an  entry  call 
Identification  (similarly  y  and  z). 


Figure  2.  A  task  with  one  entry. 

The  purpose  of  phase  one,  In  this 
example,  1r  to  insure  that  the 
WRITE'S  entry  queue  Is  in  the 
predetermined  order  at  the 
reproduction  execution,  which  l# 
(x.y.zj.  Figure  3  depicts  how  Phase 
One  handles  this  problem.  Each  entry 
call  to  the  WRjTE  entry  Is  extended 
Into  two  calls. 

The  firot  coll  Is  to  an  ATC  that 
handles  task  K.  Th.s  first  call  is 
called  the  sign-in  cull.  The  purpose 
of  this  call  is  to  get  an  entry  call 
sequence  number,  which  corresponds  to 
the  order  of  the  call  at  the  WRITE'S 
entry  queue.  Tasks  x,  y,  and  z  can 
call  the  Ada  task  controller  in  any 
order,  but  they  will  always  get  the 
same  entry  call  sequence  number, 
e.g.,  the  call  issued  by  task  z  to 
the  ATC  will  return  an  entry  call 
sequence  number  of  throe. 


Figure  3.  Sign-in  calls  in  phase  one. 
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The  second  call  uses  the  entry  call 
sequence  number  to  call  the  original 
entry  using  an  entry  family  approach. 
Task  z  Issues  the  entry  call  WRITE(3). 
These  two  entry  calls  are  similar  to 
the  two-stage  slgn-ln  process 
suggested  for  explicit  scheduling  in 
reference  [12]. 

To  preserve  the  order  of  calls,  the 
WRITE  entry  accepts  one  call  at  a 
time  using  an  entry  family  and  a  loop 
with  an  entry  family  Index  (1),  which 
Is  Initialized  to  one  and  Incremented 
by  one  every  time  the  entry  Is 
Involved  In  a  rendezvous.  Koto,  the 
calls  to  VRXTE(l)  can  only  be  accepted 
In  the  following  order:  WRXTE(l), 
VRITEU),  and  writk(3).  This  preserves 
the  original  (x.y.z)  entry  calls 
sequence,  A  loop  Is  required  If  no 
loop  already  exists,  and  an  entry 
family  index  Is  required  ns  shown  in 
Figure  3.  The  loop  stops  when  no  more 
calls  are  Issued  to  the  entry.  In 
summary,  the  number  of  Iterations  an 
entry  goes  through  Is  equal  to  the 
number  or  calls  (rendezvous)  In  which 
the  entry  Is  involved. 

The  ATC  that  handles  task  K  should 
have  an  access  to  the  predetermined 
entry  calls  sequence  of  the  WRITE'S 
entry.  This  enables  It  to  assign  an 
entry  call  sequence  number  to  each 
call  It  receives.  The  ATC  recognizes  a 
call  by  the  identity  of  the  calling 
task,  which  should  be  passed  to  the 
ATC  ns  an  input  parameter  by  the  slgn- 
ln  call.  In  the  approach.  It  Is  part 
of  the  preprocessor  to  build  an  entry 
calls  sequence  for  each  entry  within  a 
task  from  the  task's  local  rendezvous 
sequence.  It  Is  also  part  of  the 
preprocessor  to  make  these  sequences 
accessible  to  the  appropriate  ATC. 

Let  us  now  assume  that  there  arc 
two  entries  in  task  K,  a  READ  and  a 
WRITE.  In  this  case,  two  entry  call 
sequences  arc  built  from  a  task's 
local  rendezvous  sequence,  one  for 
each  entry.  We  will  also  use  two 
entry  family  indices.  An  ATC  In  this 
case  treats  each  sequence 
Independently  of  the  other.  The  ATC 
assigns  an  entry  call  sequence  number 
according  to  the  calling’s  tusk  name 
and  the  called 's  entry  name.  These 
two  names  are  passed  as  parameters  by 
the  slgn-ln  call  (refer  to  the  READ 
procedure  In  Appendix  II).  This  means 
that  the  above  discussion  regarding 


entry  extension  applies  to  multiple 
entries  regardless  of  the  number  of 
entries  within  a  task.  The  only 
difference  Is  that  an  ATC  has  to 
control  one  more  entry  calla  sequence 
for  each  additional  entry.  The 
conclusion  Is  that  each  entry  Is 
extended  Into  an  entry  family  with  an 
initial  entry  family  Index  of  one  and 
a  limit  of  the  number  of  entry  calls 
to  an  entry. 

It  is  clear  from  the  above 
discussion  that  the  original  Ada 
source  program  should  be  extended  to 
accommodate  new  Ada  code  for  the 
purpose  of  reproduction.  A  summary  of 
the  extension  procedure  used  In  this 
phase  Is  ax  follows: 

1.  Each  entry  call  Is  extended  Into 
two  calls,  a  slgn-ln  call  and  a 
call  to  the  original  entry  using 
an  entry  fni-'ly  approach. 

2.  Each  accept  Is  extended  to  an 
entry  family,  a  loop  (If 
required),  and  an  entry  family 
Index. 

3.  An  ATC  is  created  for  each  task 
(or  a  group  of  tasks)  to  handle 
entry  calls  sequences,  which  are 
provided  by  the  next  step  of 
this  list. 

4.  A  sequenca  of  entry  calls  Is 
built  from  a  local  rendezvous 
sequence  of  a  task  for  each 
entry  it  contains. 

These  extensions  are  problem 
Independent.  The  npproach  assumes 
that  these  extensions  are  part  of  the 
preprocessor.  Refer  to  example  one 
for  more  about  these  extensions. 

4.2  Nondetermlnlstlc  Selections 
Control 

In  Phase  One,  we  tried  to  Insure 
that  entry  calls  to  every  task  arrive 
In  a  predetermined  order.  This  phase 
Insures  that  a  task  selects  a 
predetermined  sequence  of  selections 
from  a  set  of  different  alternatives 
available  to  it.  We  mentioned  earlier 
that  the  selective  wait  statement  is 
what  makes  an  Ada  task  selects  a 
different  selection  from  the  same  set 
of  alternatives  every  time  it  Is 
executed  (local  nondeterminism).  The 
approach  handles  local  nondeterminism 
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**y  handling  the  selective  welt 
statement.  Ve  assume  that  no 
rendezvous  nesting  exists  within  the 
selective  wait  statement.  The  other 
types  of  select  statement,  namely  the 
conditional  entry  c“'l  and  the  timed 
entry  call,  are  t  handled  by  the 
approach.  Althoug  approach  similar 
to  the  one  given  l  >'ferencc  (21)  can 
be  adopted.  The  ap,  ,ch  also  does  not 
handle  the  CQUffT  attribute  and  shared 
variables.  An  approach  for  handling 
theso  two  attributes  is  given  in 
reference  [21). 

In  this  phase,  Mach  task  follows 
its  own  local  rendezvous  sequence. 
This  is  done  in  tvo  steps:  Step  One 
is  to  extend  t  r.ch  task  in  an  Ada 
source  program  to  include  a  liBt  of 
its  own  local  rendezvous  sequence; 
Step  Two  is  to  include  a  condition  in 
each  entry's  Vhen-clause  that  matches 
its  own  name  with  the  entry  name  at 
the  top  of  the  task's  local 
rendezvous  sequence  to  which  it 
belongs.  The  top  of  a  local 
rendezvous  scquonco  is  determined  by 
using  a  rendezvous  lndox  which  is 
initialized  to  one  and  Incremented  by 
one  nfter  every  rendezvous  that 
occurs  within  the  same  loop  (refer  to 
RV  task  in  Appendix  II). 

Conditions  serve  ns  guards  to 
entries  (14).  In  the  sot  of 
conditions,  only  one  condition  is 
always  true.  The  true  condition 
allows  the  rendezvous  at  the  top  of 
the  local  rendezvous  sequence  to 
occur.  The  false  conditions  prevent 
any  other  rendezvous  to  occur.  The 
When-clausc  always  signals  the  entry 
that  the  task  should  be  involved  in 
next.  The  other  partner  of  tha 
rendezvous,  which  is  viewed  as  an 
entry  call  by  the  destination  task, 
is  provided  by  Phase  One  of  the 
approach.  After  each  rendezvous,  an 
index  that  points  to  the  next 
rendezvous  in  the  local  rendezvous 
sequence  is  incremented  by  one. 

To  see  how  the  two  phases  work 
together,  assume  that  a  task  is  used 
with  two  entries,  READ  and  WRITE.  A 
local  rendezvous  sequence  of  this 
task  is  (  <l,x,READ>,  <2,y,VRITE> 
, <3 ,z ,READ> ) .  This  three-rendezvous 
list  contains  three  sub-lists.  Each 
sublist  represents  a  rendezvous.  Each 
subllst  contains  three  entities:  a 
rendezvous  sequence  number,  a  name  of 


a  calling  task,  and  a  called  entry 
name.  Assume  also  that  the  entry 
calls  coming  from  taskR  x,  y,  and  z 
arrive  in  a  predetermined  order  by 
Phase  One.  The  task  has  a  loop  that 
iterate  three  times  and  involves  in 
three  rendezvous  then  terminates  (sec 
Figure  4). 

When  executing  task  G  (Figure  4) 
and  during  the  first  iteration,  the 
READ  and  WRITE  alternatives  are 
available.  The  READ'S  Whcn-clause 
become*  true  because  It  was  involved 
in  the  first  rendezvous.  The  WRITE'* 
Whcn-clause  becomes  false.  So  the 
READ  entry  is  selected  for  the  first 
rendezvous.  The  other  partner  of  the 
rendezvous  la  task  x.  By  assumption, 
the  entry  call  from  task  x  to  the 
READ  entry  is  at  the  top  of  the  READ'S 
entry  queue.  The  two  partners  of  the 
first  rendezvous  now  match  and  the 
rendezvous  occur.  The  two  other 
rendezvous  nro  reproduced  in  the  same 
way. 

This  phase  requires  some  extensions 
to  an  Ada  source  program.  The  first 
extension  is  to  mnkc  each  tnsk  in  a 
program  nccess  its  own  local 
rendezvous  sequence.  A  local 
rendezvous  sequence  is  represented  ns 
an  array  of  entry  nnmes.  A  rendezvous 
index  is  needed  to  point  to  the  next 
rendezvous  in  the  sequence.  The  last 
rendezvous  occurs  at  the  last 
iteration  of  the  selective  wait 
statement. 


Figure  4.  A  tnsk  with  two  entries. 

The  second  extension  is  to  include 
in  each  entry’s  When-clause  c 
condition  that  matches  the  entry's 
own  name  with  the  name  of  the  entry 
at  the  top  of  the  task's  local 
rendezvous  sequence.  The  approach 
assumes  that  these  two  extensions  are 
part  of  the  preprocessor.  The  next 
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section  explains  the  reproduction 
process  of  an  extended  Ada  program. 


5.  A  COMPLETE  EXAMPLE 

An  Ada  program  is  listed  in 
Appendix  I  C 12 j .  The  program  is  a 
controller  for  a  shared  resource  that 
allows  multiple  readers  at  the  same 
time  and  only  one  writer  at  a  time. 
In  this  example,  wo  plan  an  execution 
scenario  of  the  program  and  then 
determine  how  this  scenario  is 
specified.  We  also  explain  the  needed 
extensions  to  the  original  program. 


assumed  to  be  demanding  tasks  (refer 
to  the  end  of  Section  3  for  the 
definition  of  a  demanding  task),  and 
as  a  result,  no  local  rendezvous 

sequences  nre  specified  for  them. 

When  this  path  specification  Is 

read  by  the  preprocessor.  It  builds  a 
sequence  of  entry  calls  for  each 

entry  In  the  KW  task.  The  preprocessor 
builds  the  following  entry  calls 

sequences. 

START  READ  SEQ  :-  (Cl,  C2,  C4 ) 

END  READ  SEQ  (Cl,  C2,  C4  ) 

START  WRITE  SEQ  (C3) 

END  WRITE  SEQ  (C3) 


EXAMPLE  1 ; 

Using  the  Ada  code  In  Appendix  I, 
assume  that  there  arc  four  demanding 
tasks  Cl,  C2 ,  C3,  and  C4  that  use  the 
RESOURCE  package.  Further  assume  that 
Cl  and  C2  called  RW  for  reading  the 
rosource  whore  Cl  called  before  C2. 
Task  C3  called  Tor  writing  while  Cl 
and  C2  vero  still  In  the  process  of 
reading.  Task  C4  called  for  reading 
after  C3  had  finished  writing.  Because 
task  RW  has  an  Infinite  loop,  assume 
horc  that  the  number  of  readers  and 
writers  are  finite  and  It  will 
terminate. 


To  specify  the  nbove  scenario,  wo 
need  to  determine  a  local  rendezvous 
sequence  that  represents  the  above 
path.  One  possible  local  rendezvous 
sequence  Is: 


LRS1  : -  ( 

<2, Cl, END  READ> , 
<4,C2,END“READ>, 
<6.C3,END“WRITE>. 
<8. C4, END-READ >  ) 


<1, Cl, START  READ>  , 
<3, C2. START-READ >, 
<5, C3, START  WRITE)  , 
<7, C4, START  READ)  , 


Recall  that  each  rendezvous  Is 
represented  us: 

(Rendezvous  sequence  number,  Calling 
task  Identity,  Entry  name). 


Rendezvous  2  and  3  can  bo  exchanged 
to  get  another  local  rendezvous 
sequence  that  v*  1 1 11  represents  the 
same  path.  The  above  local  rendezvous 
sequence  is  a  path  specification  for 
the  program  in  Appendix  I  with  the 
execution  scenario  explained  above. 
LRS1  Is  the  content  of  the  path 
specification  file  (see  Figure  1). 
Note  that  tasks  Cl,  C2,  C3,  and  C4  are 


This  set  of  entry  calls  sequences 
are  then  built  Into  an  ATC  for  task  RW 
(refer  to  RW_C  task  In  Appendix  II). 
The  preprocessor  creates  the  RW_C  a« 
an  Ada  task  controller  for  RW  task  and 
adds  it  to  the  original  Ada  source 
program.  Note  that  It  should  be 
specified  that  an  ATC  be  built  for  the 
RW  task  in  the  preprocessor  command 
file.  The  preprocessor  also  extends  on 
Ada  program  according  to  the  extension 
procedures  of  the  two  phases  given  In 
subsections  4.1  and  4.2.  Appendix  II 
lists  the  progrnm  after  It  has  been 
extended  by  the  preprocessor. 

Thero  are  two  pneknges  In  Appendix 
II:  the  RESOURCE  packngc  and  a 

CONTROLLER  package.  The  RESOURCE 
pnekngo  is  extended  to  accommodate 
now  Ada  code.  A  symbol  at  Che  end  of 
a  lino  indicates  how  much  a  line  is 
extended.  The  symbol  " — 0"  Indicates 
that  the  line  is  added  completely  to 
the  original  progrnm.  The  symbol 
&"  indicates  that  some  extension 
occurred  in  the  line.  Note  that  tho 
CONTROLLER  package  Is  completely 
added  so  there  Is  no  need  for  using 
any  symbols. 

Note  how  each  call  to  the  RW  task  Is 
extended  in  the  READ  and  WRITE 
procedures  as  a  result  of  the  entry 
calls  control  phase.  The  slgn-ln  call 
to  the  controller  (RW_C)  Includes  tho 
caller  identif IcationT  the  requested 
entry  name,  and  a  dummy  parameter  to 
return  an  entry  sequence  number.  Tho 
original  call  is  extended  to  Include 
the  entry  call  sequence  number 
(ENTRY  CALL_SEQ_NO ) .  Note  also  how 
each  entry”  is  extended  in  the  RW 
task.  Each  entry  is  extended  to  a 
family  of  entries  and  has  its  own 
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family  of  entry  index.  These  extension 
arc  part  of  Phase  One;  the  rest  of  the 
extensions  In  the  RV  task  are  part  of 
Phase  two.  However,  the  CONTROLLER 
package  Is  a  result  of  the  extensions 
In  Phase  One. 

Note  also  how  each  entry's  When- 
clausc  was  extended  to  Include  an 
additional  condition  and  how  the 
while  loop  keep  track  of  the  number 
of  rendezvous  for  reproduction  using 
the  rendezvous  Index  (NEXT_R).  Note 
also  how  the  local  rendezvous 
sequence  (LOCAL_REND_SEQ)  Is 
represented.  These  “extensions  are  a 
result  of  the  nondoterministlc 
selections  control  phase. 

As  a  result  of  these  extensions, 
the  specification  of  the  RESOURCE 
package,  and  the  RV  task  were 
extended.  The  program  given  in 
Appendix  II  Is  a  deterministic 
version  or  the  original  program  In 
Appendix  I,  and  It  will  always 
follows  the  same  path  (spoclfled  by 
LRS1)  every  time  it  Is  exocutod. 


6.  CONCLUSIONS 

Reproduction  of  Ada  tasking 
programs  Is  a  problem  that  must  be 
dealt  with  In  cyclic  debugging  of  Ada 
programs.  The  method  of  avoiding  the 
problem  by  building  a  debugger  that 
has  the  ability  to  discover  and 
locate  errors  Is  inadequate  because 
this  method  mixes  the  testing  and 
debugging  phases,  is  complex,  and  is 
expensive.  The  method  of  extending  a 
nondoterministlc  program  Into  a 
deterministic  one  Is  adequate  because 
It  Is  easy  to  understand  and  to 
Implement;  however,  the  problem  Is 
difficult  In  Ada  because  of  the 
asymmetric  naming  convention  to  the 
way  Ada  handles  ontry  queues.  The 
approach  distinguishes  between  two 
types  of  nondotorminism;  global 
nondeterminism  and  local 
nondctcrmlnism.  It  handles  each  type 
separately.  The  approach  extends  a 
nondoterministlc  Ada  tasking  program 
Into  a  deterministic  one.  This  Is  done 
in  two  phases:  Phase  One  handles 
global  nondeterminism,  and  Phase  Two 
handles  local  nondctermlnisra.  Globa: 
nondotorminism  is  handled  by  using 
one  Ada  task  controller  per  task  to 
control  the  arrival  sequence  of  calls 
to  a  destination  task.  Having  more 


than  one  controller  eliminates  the 
need  for  a  mastor  controller  that  can 
be  a  bottleneck  to  the  reproduction 
process.  Local  nondotorminism  is 
handled  by  restricting  the  number  of 
open  alternatives  in  a  selective  wait 
statement  using  a  Vhen-clnuoe  ns  a 
guard  to  each  alternative.  The  method 
is  easy  to  understand  and  to 
Implement. 

APPENDIX  I 

package  body  RESOURCE  Is 
S  :  SHARED_DATA  :*•  —  The  shared  data 

task  RW  Is 
entry  START_READ; 
entry  END  READ; 
entry  START  WRITE; 
entry  END_WRITE; 
end  RW; 

task  body  RW  Is 

NO  READERS:  NATURAL  0; 
WRTTER_PRESENT:  BOOLEAN  FALSE; 
bogln  “ 
loop 
select 

when  not  WRITER_PRESENT  -> 

accept  START  READ; 
N0_READERS  NO_READERS  +  1: 
or 

accept  END  READ; 

N0_READERS~: -  NO_READERS  -  1; 
or 

when  not  WRITER  PRESENT  AND 
NO_READERS  -  0  “> 

accept  START  WRITE; 
WRITER_PRESENT  TRUE? 
or 

accept  END_WRITE; 

WRITER_PRESENT  FALSE; 
end  select; 
end  loop; 
end  RW; 

procedure  READ  (X:out  SHAREDJJATA)  is 
begin 

RW. START  READ; 

X  S; 

RW.END_READ; 
end  READ? 

procedure  WRITE(X  :  in  SHARED_DATA)  Is 
begin 

RW. START  WRITE; 

S  X; 

RW. END_WRITE; 
end  WRITE; 
end  RESOURCE; 
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APPENDIX  II 


with  CONTROLLER:  —8 

package  RESOURCE  la 

use  CONTROLLER;  —8 

type  SHAREDJDATA  la  . . . ; 
procedure  READ( CALLER  ID: in 

CALLER  NAME;  — & 

X  :  out  SHARED_DATA ) ; 

procedure  WRITE( CALLER  ID  :  in 

CALLER  NAME;-  —A 

X  :  in- SHARED  DATA); 


end  RESOURCE; 

package  body  RESOURCE  is 
S  :  SHARED  DATA  —  The  sharod  data 


task  RW  is 

entry  START  READ(REND  INDEX);  —A 

entry  END_READ(REND  INDEX);  —A 

entry  START_WRITE(REND_INDEX ) ;  —A 

entry  END_WRITE(REND_INDEX) ;  —A 

end  RW; 

task  body  RW  is 

LOCAL  REND_SEO: RENDEZVOUS  LIST;  —8 

NEXT  K  :  REND  INDEX  :~1;  “  —8 

SR , ER  , SW , EW : REND  INDEX  1;  —8 

LOCAL  REND_SEO  “(l  ..  8)  :~ 

(START-READ.  £ND_READ,  — 0 

START  READ.  END_READ ,  —8 

START-WRITE,  END_WRITE,  —8 

START- READ ,  END  READ);  —8 

NO  READERS:  NATURAL  :-  0; 


WRITER  PRESENT:  BOOLEAN  :-  FALSE: 


or 

when  LOCAL_REND_SEQ ( NEXT_R )- 


“  END  WRITE  ->  —8 

accept  END  VRITE(EV);  —A 

WRITER  PRESENT  : -"FALSE; 

EW  EW  +  i;  --8 

end  select; 

NEXT_R  :-  NEXT.R  +  1;  —8 

end  Toop; 
end  RW; 


Procedure  READ( CALLER  ID  :in 

CALLER_NAME;  X  :out  SHARED_DATA)  is 
begin  - 

RW  C.SIGN  IN(CALLER_ID. 

START  READ, ENTRY  CALL  SEQ_NO);  —8 
RW. START  READ( 

ENTRY_CAM._SEQ_NO ) ;  —A 

X  :  S  ■ 

RW* C.SIGN  IN( CALLER  ID.  END_READ. 

-  ENTRY  CALL  SEO  NO);  — 

RW.END  READ( ENTRY- CALL- SEO_NO ) ;  — 

end  READ- 

procedure  WRITE( CALLER_IP  :in 

CALLER_NAME;  X  :ln  SHARED_DATA )  is 
begin 

RW  C.SIGN  IN(CAI.LER_ID,  START  WRITE, 

-  ENTRY  CALL  SEQ_NO);  —8 
RW. START  WRITE( 

ENTRY  CALL  SEQ_NO);  —A 

S  X ; 

RW* C.SIGN  IN( CALLER  ID.  END_WRITE, 

ENTRY  CALL  SEO  NO);  —8 
RW .  END_WRITE(  ENTRY-CAUTSEQ_NO ) ;  —A 
end  WRITE; 
end  RESOURCE: 


begin 

while  NEXT  R  <- 

-  RW_REND_INDEX_LIMIT  —8 

loop 

8Cl6C t 

when  not  WRITER  PRESENT  and 
LOCAL_REND  SEQ(NEXT  R)  - 
START  READ  ->  —8 

accept  START_READ(SR) ;  —A 

NO  READERS  :-  NO  READERS  +  1: 

SR-  :-  SR  +  I;  —8 

or 

when  LOCAL  REND  SEO(NEXTJR)  - 
END  READ-Taccept  END_READ(ER);  —A 
NO_READERS  :-  NO  READERS  -  1; 

ER  :-  ER  +  l;  —8 

or 

when  not  WRITER  PRESENT  and 
NO  READERS  -  0  and 
LOCAL  REND_SEQ(NEXT  R)  - 
START- WRITE  ->  ~  — 0 

accept  START  WRITE(SW);  —A 

WR ITER_PRESENT  TRUE; 

SW  :-  SW  +1;  —8 


package  CONTROLLER  is 

type  ENTRY  NAME  is  (STARTJtEAD. 
END_READ,START_WRITE,  END_WRITE) : 

RW_REND_INDEX_LIMIT  :  constant  :-  8; 

type  REND_INDEX  is  POSITIVE: 

type  RENDEZVOUS  LIST  is  array 
REND_INDEX)  of  ENTRY_NAME; 

type  CALLER_NAME  is  (Cl,  C2,  C3,  C4); 

type  ENTRY  QUEUE  is  array(REND_INDEX ) 

of  CALLER_NAME; 

procedure  SEARCH(  SEQUENCE  :  in  out 

ENTRY  OUEUE; 
ID  :  in  CALLERlNAME; 
OUT_NO  :  out  REND_INDEX ) : 
end  CONTROLLER: 
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c 


package  body  CONTROLLER  Is 

rnnk  SV  C  <  ft 

entry  SIGN  IN  (CALLER  ID  :  in 
CALLER  NAME; 

ENTRY  REO  :  In  ENTRY  NAME; 

CALL_SEO  NO  :  out  REND  INDEX); 
end  RW_C; 

task  body  RW_C  is 

CALL  INDEX  :  INTEGER  0; 

START  READ  SEQ,  END  READ  SEQ  : 

ENTRY-QUEUE; 

STAKT_VRITE  SEQ,  END  WRlT£_SEO  : 

ENTRY  QUEUE; 

START  READ  SEQ  (1  ..  3  ) : -TCI , C2 , C4 ) ; 
END  READ  SEQ  (1  ..  3)  (C1.C2.C4); 

START  WRITE  SEQ  (1)  (C3); 

END_WkITE_SEO  (l)  (C3); 

begin 
loop 

when  CALL  INDEX <~ 

RW  REND  INDEX-LIMIT  ~> 

“  accept  5IGN_IN  (CALLER  ID  :  in 

CALLER  NAME; 
ENTRY  REQ  :  in  ENTRY~NAME; 
CALL_SEOlNO  :  out  RENdJTNDEX )  do 
case  ENTRY- REQ  is 
when  START-READ  -> 

SEARCH ( START_READ_SEQ ; 

CALLEK_ID; 

CALL  SEQ_NO ) ; 
when  END_READ  -> 

SEARCH( END_READ_SEQ ; 

CALLER_ID; 

CALL  SEQ  NO); 
when  START  WRITE-- > 
SEARCH(START_WRITE  SEQ; 

CALLER  ID; 

CALL  SEQ  NO); 
when  END_WRITE  ->  “ 

SEARCH (END  WRITE  SEQ; 

- CALLEK_ID; 

CALL_SEQ_NO ) ; 
when  others  ->  null; 
end  case; 
end  SIGN  IN; 

CALL_INDEX  CALL_INDEX  +  1; 
end  loop; 
end  RW_C; 

procedure  SEARCH (  SEQUENCE  :  in  out 

ENTRY_QUEUE; 

ID  :  in  CALLF.R_NAME; 
OUT_NO  :  out  REND_INDEX )  is 

begin 

INDEX  1; 

while  INDEX  <-  SEQUENCE’ LENGTH 
loop 

if  SEQUENCE( INDEX )  -  ID  then 
OUT_NO  INDEX; 

SE0UENCE( INDEX)  null; 


exit; 

else 

INDEX  INDEX  +  1; 

end  if; 
end  loop; 

end  SEARCH: 

end  CONTROLLER; 
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Abiluct 

Developing  an  understanding  of  object 
oriented  programming  in  Ada  presents 
challenges  for  the  experienced  programmer. 
The  project  presented  is  a  text  adventure 
game  using  object  oriented  methodology  and 
Ada.  We  can  improve  the  learning  process 
Involved  in  these  topics  by  examining  the 
barriers  encountered  by  a  student  while 
designing  this  project. 


Inlr.gducllgn 

Learning  a  new  programming  method  can 
be  difficult.  As  a  student  learning  object 
oriented  programming  this  challenge  was 
faced.  The  project  presented  was  to  learn 
object  oriented  design  and  Ada  by  developing 
a  text  adventure  game.  The  goal  of  this 
project  was  to  become  familiar  with  the  Ada 
programming  language  and  to  gain  an 
understanding  of  object  oriented 
programming.  The  major  barrier  encountered 
was  to  break  out  of  the  rooted  procedural 
style  of  programming  and  adopt  object 
oriented  style.  Due  to  inexperience  in  the 
object  oriented  technique,  problems  were 
encountered  throughout  the  stages  of 
development.  Dealing  with  these  problems 
led  to  a  greater  level  of  understanding.  This 
paper  describes  important  issues  Involved  in 
the  design  and  implementation  of  a  major 
programming  task  using  object  oriented 
programming  in  the  Ada  environment. 


Ei.oi.fcm_J?.e.acrlBUQn 

The  project  was  presented  in  the  first 
quarter  of  a  three  quarter  software 
engineering  class.  An  open  specification  of 
the  problem  was  given,  allowing  the 
programmers  to  expand  on  the  design.  The 
original  concept  was  to  create  a  dungeon  or 
maze  made  up  of  Interconnected  rooms.  The 
goal  of  the  game  is  to  collect  treasure  found 
in  these  rooms  and  rescue  the  kidnapped 
princess.  The  final  program  included  the 
rooms  and  objects,  but  also  added  creatures 
and  doors. 

The  player  moves  from  room  to  room 
collecting  treasure.  When  a  room  is  entered, 
a  description  of  the  room  is  given  along  with 
the  names  of  the  creatures  and  treasure  it 
contains.  Treasure  within  the  rooms  carry 
point  values  that  are  added  to  the  player's 
score  when  picked  up  and  subtracted  when 
dropped.  There  are  four  subclasses  of  items: 
general  treasure  (worth  varying  point  values), 
Heavy  treasure  (worth  negative  point  values), 
weapons  (needed  to  kill  creatures),  and  keys 
(to  lock  and  unlock  doors). 

Commands  that  can  be  used  by  the 
player  include  operations  on  treasure, 
creatures,  doors,  and  other  miscellaneous 
commands.  The  player  takes,  drops,  and 
examines  treasure.  When  a  player  is  In  the 
same  room  as  a  creature  the  croature  is 
talked  to,  examined,  and  attacked.  A  creature 
is  killed  when  the  player  is  carrying  a  weapon 
and  is  stronger  than  the  creature.  Doors  are 
locked,  unlocked,  opened,  and  closed.  Locking 
and  unlocking  can  only  be  done  when  the 
player  is  carrying  a  key.  Other  commands 
allow  a  user  to  move  from  room  to  room, 
check  to  see  what  objects  are  being  carried, 
view  a  help  screen,  and  quit  the  game. 
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Project  Ptvtlppmtnt 
Idintltvino  tht  Qbitcti. 

Objects  are  the  entities  In  the  problem 
that  act  as  nouns.jlj  A  good  understanding  of 
objects  is  obtained  by  imagining  them  as 
being  people.  Each  person  has  traits  that  are 
represented  by  fields  in  the  object. 

There  were  five  objects  in  the  initial 
project  design:  rooms,  corridors,  doors, 
items,  and  creatures.  The  object  named 
creatures,  when  first  defined,  contained  the 
fields  and  operations  for  the  player  and  the 
monsters.  After  examining  the  combination, 
it  was  found  that  the  player  and  creature 
were  two  separate  types  with  little  overlap 
in  operations.  The  creature  object  was  then 
split  into  the  objects  creatures  (monsters) 
and  player.  Realizing  that  the  player  and 
monster  objects  were  separate,  led  to  an 
understanding  of  cohesion  in  objects. [2] 
Another  refinement  occurred  between  the 
rooms  object  and  the  corridors  object. 
Analyzing  the  description  of  the  two  objects 
forced  the  realization  that  the  two  were 
essentially  the  same.  By  combining  the  two 
objects  an  increased  understanding  of  well 
defined  abstract  data  types  evolved.  After 
refinement,  the  object  identification  was 
complete.  The  final  Identification  of  the 
objects  included  an  object  for  each  of  the 
following:  rooms  and  corridors,  doors,  items, 
creatures  and  player. 

IdinillYinq  tha  Qperitlona. 

The  operations  in  the  problem  are  the 
entities  that  act  as  verbs. [1]  Operations 
allow  fields  within  an  object  to  be  accessed 
or  changed.  Operations  must  be  complete.  In 
order  for  an  object  to  be  complete,  the 
operations  must  allow  access  to  all  of  the 
visible  fields  in  the  object.  Using  the  analogy 
of  objects  as  people,  the  operations  can  bo 
thought  of  as  interactions  between  people. 
One  person  may  request  information  from 
another  or  may  attempt  to  change  that  person 
(sometimes  a  person  will  talk  to  themselves). 

One  of  the  major  problems  encountered 
in  designing  this  project  was  identifying  the 
operations.  At  first  the  operations  seemed 
logical  and  complete  but  when  establishing 
the  interface,  the  operations  were  found  to  be 


incomplete.  The  initial  identification  of  the 
operations  did  not  take  into  consideration  the 
strict  enforcement  of  information  hiding. 
When  it  came  time  to  establish  the  interface, 
it  was  realized  that  extra  operations  were 
noeded  to  manipulate  the  objects.  It  was  at 
this  point  that  an  understanding  of  how  to 
define  complete  operations  was  developed. 

£alibllaihln.a-Jh»  Viability, 

The  visibility  is  determined  by  the 
relationships  between  the  objects.  One 
object  is  visible  to  another  if  it  is  used  by 
the  other  object.  Person  A  is  visible  to 
Person  B  if  B  asks  A  questions. 

When  establishing  the  visibility,  two 
problems  were  encountered:  over-dependent 
objects  and  codependent  objects.  The  over¬ 
dependence  of  the  objects  was  shown  by  the 
dependency  graph.  The  number  of  connections 
going  from  a  major  object  to  other  major 
objects  was  large.  Codependency  is  caused 
when  two  objects  must  be  visible  to  each 
other.  Ada  does  not  permit  codependency. 
When  using  the  with  statement  to  establish 
visibility  of  an  object,  the  packages  being 
accessed  must  be  compiled  before  the 
accessing  package  can  be  compiled.  If  two 
objects  must  be  visible  to  each  other  then  it 
would  be  impossible  to  compile  them.  In  the 
project,  both  the  over-dependency  and  the 
codependency  was  caused  by  poor  design. 
Major  objects  would  access  each  other  in 
order  to  perform  commands.  To  remove  this 
problem  a  hierarchy  of  objects  was  instituted 
(see  figure  1).  The  upper  level  of  the 
hierarchy  controlled  the  command  flow  by 
accessing  the  major  objects.  This  solution  to 
this  problem  brought  to  light  the  importance 
of  structure  in  defining  object  interaction. 

Eitibtishing  the  interface. 

The  interface  defines  what  other 
objects  are  allowed  to  access  in  a  particular 
object.  No  problems  arose  from  using  the 
module  specifications  to  establish  the 
interface.  Very  explicit  rules  of  information 
hiding  were  required  in  the  project 
specification.  By  requiring  the  use  of  private 
types  in  package  specifications,  information 
hiding  was  enforced. 
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Dependency  Graph 


£l»in-l 


Implcmftnllnfl  the.  Pblacla. 

Objects  are  implemented  by 
transferring  the  object  oriented 
representation  into  Ada  code.  A  design 
barrier  involving  message  passing  was 
introduced  while  implementing  the  objects. 
The  problem  arose  when  trying  to  implement 
how  a  player  or  a  room  could  possess 
treasure.  Information  hiding  does  not  allow 
either  tne  room/corridor  object  or  the  player 
object  to  actually  access  the  items 
implementation.  The  problem  was  solved  by 
the  implementation  of  access  types.  The 
access  type  identifies  the  item  that  is  being 
passed  from  object  to  object.  The 
understanding  of  how  to  implement  objects 
while  following  the  rules  of  information 
hiding  was  improved  by  overcoming  this 
difficulty. 


Following  are  the  five  major  areas  in 
which  learning  difficulties  occurred: 

1.  Defining  objects  that  follow  the  rules  of 
abstract  data  types. 

2.  Defining  complete  operations. 

3.  Structuring  tho  object  organization. 

4.  Implementing  communication  between 
objects. 

Since  the  lab  was  designed  so  that  the  object 
oriented  methodology  would  be  learned  by 
doing,  a  solution  to  each  problem  marked  a 
landmark  in  the  learning  process.  The  use  of 
the  Ada  programming  language  facilitated  the 
object  orionted  design  due  to  the 
Implementation  of  packages  and  private 
types.  An  Introduction  \o  the  object  oriented 
programming  method  gave  a  good 
understanding  of  the  process.  When  the 
object  oriented  programming  method  was 
applied,  a  complete  understanding  of  the 
method  was  gained.  It  is  hoped  that,  through 
examining  the  process  involved  in  learning 
object  oriented  programming  in  Ada,  the 
understanding  of  these  concepts  and  how  they 
are  presented  can  improve. 
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Abstract.  One  of  Ada's  nost  powerful 
features  is  the  ability  to  develop 
general  algorithms  to  work  in  a  variety 
of  different  situations.  The  widespread 
use  of  goneric  units  will  help  Ada  become 
the  high  lcvol  design  language  that  it  is 
intended  to  be.  However,  the  devolopnant 
of  goneric  units  can  be  a  difficult 
process  and  there  ara  many  things  to  be 
considered.  Most  importantly,  care  must 
be  taken  to  ensure  that  tho  generic  units 
aro  designed  in  such  a  manner  as  to 
encourage  thoir  use.  This  paper  will 
give  practical  examples  of  a  generic  unit 
written  in  ways  that  will  both  encourage 
and  discourago  its  use.  These  examples 
will  show  how  careless  design  of  generic 
units  can  load  to  the  lnprocticality  and 
failure  of  gonerics  as  a  powerful  feature 
of  Ada. 


While  working  in  tho  software 
engineering  industry  as  an  intern  I  had 
an  opportunity  to  be  taught  Ada,  have 
access  to  a  great  deal  of  literature  on 
Ada,  and  have  tho  opportunity  to  spend 
time  working  with  tho  language.  Early 
on,  nany  lessons  were  taught  about  what 
made  Ada  a  different  and  useful  language. 
By  tho  end  of  my  stay  as  an  intern,  tho 
nore  powerful  features  of  Ada  had  been 
revealed.  The  reasons  for  use  and  tho 
methods  of  use  were  also  woll  explained. 
One  of  the  features  that  seemed  to  bo  the 
most  poworful  and  beneficial  to  the 
overall  purpose  of  the  Ada  language  was 
generics. 

I  found  that  when  a  beginner  is 
being  taught  about  generics,  the  idea  of 
total  abstraction  from  data  as  tho  goal 
of  generics  was  very  strongly  emphasized. 
In  the  same  respect,  examples  were 
produced  that  led  to  very  nice  results 
that  displayed  a  very  high  level  of 
abstraction  from  data.  However,  it  is 
only  through  handpicking  these  examples 
that  an  "easy"  solution  renders  itself. 


Later,  upon  continuing  study  and 
aftor  working  with  many  problems  using 
gonerics  for  a  variety  of  practical 
applications,  I  realized  that  my  designs 
of  many  gonoric  units  led  to  cumbersome 
and  hard  to  usa  solutions.  In  addition, 
and  nost  importantly,  I  realized  that  by 
being  awkward  and  hard  to  usa  these 
gonoric  units  defeated  thoir  own  purpose. 

This  paper  will  provide  a  practical 
example  of  a  generic  unit  that  if  not 
carefully  designed  will  lead  to  code  that 
would  defeat  tho  entire  purpose  of  it 
being  a  generic.  Tho  goneric  unit  used 
will  be  in  tho  form  of  a  generic  Sort. 
Since  total  abstraction  is  usually 
stressed,  in  teaching  generics  and  in  the 
literaturo  on  generics,  the  first  several 
examples  of  this  generic  unit  will  have 
complete  abstraction  from  the  information 
to  bo  sorted  and  tho  data  structure  that 
the  information  is  contained  within.  The 
method  of  sorting  and  therefore  the  body 
of  any  of  the  gonoric  units  aro 
completely  irrelevant  to  this  discussion 
since  the  user  of  a  generic  unit  should 
only  be  concerned  with  the  specification 
of  that  unit. 

One  example  of  a  specification  for  a 
generic  unit  that  could  be  used  to  sort 
any  type  of  data  within  any  typo  of  data 
structure  is  this  specification. 

generic 

type  ElenentJType  is  private  ; 

type  Koy_Type  is  private  ; 

type  Listjrype  is  private  ; 

Number_Of”Elemonts  :  positive  ; 

with  function  "<" 

(  Key_l  :  Koy_Type  ; 

Key_2  :  Key_Type  ) 
return  Boolean  7 

with  function  ">" 

(  Key_l:  Koy_Type  ; 

Key_2:  Key_Type  ) 
return  Boolean”; 
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with  function  Koy 

(  Element:  Elonantjrypa  ) 
roturn  Koyjrypo  j 

with  function  Naxt^Elcnont 

(  Elcnont:  Element  JTypo  ) 
roturn  ElenontJType  ; 

with  procedure  Replace 
(  OldJSloncnt:  in  out  Elcmontjrypo  ; 

Ncw"Elonont:  in  ElcnontJTypo  ); 

procedure  Sort  (  List:  in  out  Listjrypo) ; 

While  this  specification  for  a 
generic  sort  procedure  nay  seen 
ridiculous,  it  is  designed  to  bo.  It  is 
intentionally  designed  to  display,  in  tho 
worst  case,  just  how  unusable  a  generic 
unit  can  beconc.  Fortunately,  if  this 
oxampla  is  ra-thought  nuch  can  be  dona  to 
improve  it.  Tho  no3t  obvious  nogativa 
point  is  that  tharo  ora  nine  gonoric 
formal  parameters ,  six  of  which  are 
genaric  fornal  subprograms.  It  is  likaly 
that  soneona  requiring  a  sort  could  write 
a  non-gcnaric  sort  in  lass  time  than 
required  to  instantiate  this  specific 
generic  sort.  This  is  probably  trua  even 
if  very  good  documentation  was  provided 
concerning  tha  function  of  each  generic 
formal  poranatar. 

There  are  several  quite  obvious 
improvements  that  can  be  made  to 
alleviate  tho  problems  that  this  axanpla 
has  with  unnecessary  and  inhibiting 
complexity. 

1.  The  overloaded  inequality 
functions  can  be  reduced  from  two 
functions  (  i.a.  "<"  and  M>"  )  to 
just  ono  of  the  two  function  is 
always  possible. 

2.  Tho  ganaric  formal  function  that 
returns  tho  koy  of  an  olomont  is 
not  nococsary.  This  oporation  can 
bo  dona  in  conjunction  with  tho 
now  singlo  gonoric  subunit  for 
inequality. 

A  specification  taking  those  two  changes 
into  account  might  look  like  to  following 
code. 

gcnaric 

typo  Elomont_Typo  is  private  ; 

typo  ListJType  is  private  ; 

Nunber_Of~Ei.enents  :  positive  ; 


with  function 

(  Elemont_l  :  Elomontjrype  ; 

Elonent“2  :  Elanentjrypc  ) 
roturn  Dooloan  ; 

with  function  Noxt_Elonont 

(  Elomont  : "Element JTypo  ) 
return  Element_Typo  ; 

with  procedure  Replace 
(  01d_Elomont:  in  out  Elonentjrypo  ; 
Now'Elonont:  in  Elomontjrype  ); 

procedure  Sort  (  List:  in  out  List_Typo); 

With  this  obvious  adjustment  tho 
number  of  formal  paramotors  has  been 
reduced  from  nine  to  six  with  only  three 
of  these  being  generic  formal  subunits. 
This  adjustment  will  reduce  tho  overall 
complexity  of  using  tho  gonoric  unit 
somewhat,  howovor,  two  of  the  three 
remaining  generic  formal  subunits. 

Next  Element  and  Replace,  will  be  very 
difficult  for  tho  U3or  of  a  gonoric 
package  to  implemant.  This  is  duo  to  tho 
fact  that  tho  parson  using  tho  package 
must  have  a  good  fool  for  what  tho 
designer  of  tho  generic  package  had  in 
mind  for  theso  subprograms  when  writing 
tho  generic  unit. 

An  oxamplo  of  what  tho  designer 
might  havo  had  in  mind  when  designing  tho 
above  generic  unit  might  be  those 
descriptions. 

1.  Noxt_Elonont  night  bo  n  qonoric 
formal  subprogram  that  given  a 
particular  element  in  tho  external 
data  structure  would  roturn  just 
tho  data  part  of  tho  next  element 
in  tho  structure.  This  alona  would 
requiro  a  linear  search. 

2.  Replaco  would  replace  each  unsorted 
element  with  tho  sorcad  elemont 
corresponding  to  tho  unsorted 
alcnonts  position.  This  subprogram 
would  also  requiro  a  linoar  search. 

It  is  obvious  that  the  logic  of  thoso 
gonoric  fornal  subprograms  is  noro 
difficult  and  lengthy  than  they  could 
optimally  be.  This  problem  arises 
because  the  design  of  tho  generic  sort 
attempts  to  abstract  completely  nway  from 
the  data  structure  that  it  will  be 
sorting.  Since  the  two  difficult  gonoric 
formal  subunits  provide  methods  of 
transferring  the  unsorted  and  sorted 
notarial  to  and  from  the  generic 
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procedure,  then  the  only  way  to  simplify 
the  problem  is  to  find  an  cosier  mothod 
to  pro fora  these  operations. 

Traditionally,  the  way  to  sake  any 
algoritha  easier  to  understand,  is  to  use 
an  algoritha  thnt  aiaics  on  intuitive 
approach.  In  the  case  of  a  sort,  a  very 
intuitive  approach  is  available.  That 
is,  to  give  all  data  to  soaething  and  to 
expect  to  receive  the  data  back  in  sorted 
order.  This  can  be  translated  into 
copying  all  the  elements  in  the  extornal 
data  structure  into  the  internal  data 
structure,  sorting  the  internal  data 
structure,  and  then  copying  the  sorted 
elcaonts  out  to  the  external  data 
structure. 

One  elegant  way  of  achieving  this 
is  to  change  tho  generic  sort  procedure 
into  a  genoric  package  containing  an 
interface  task.  This  interface  task  can 
transfer  an  alcn&nt  fron  tho  calling  unit 
to  the  genoric  package  very  easily.  In 
this  situation  the  genoric  package  could 
look  like  this: 

generic 

type  Elomcntjrypo  is  private  j 

with  function  M<" 

(  Eleaant_l  :  ElomentJTypo  ; 

Elonont_2  :  Elonent“Typo  ) 
return  Doolaan  ; 

package  Sort_Packago  is 

task  Transfer  is 

entry  send 

(  Element  :  in  Elencnt_Typc; 

Last_Elonont:  in  Boolean”  ); 

entry  Receive 

(  Element  :  out  Elenont_Typo  ; 

Last_Elemont:  out  Boolean”  ); 

—  Mote:  Two  procedures  must  be 

—  included  in  tho  calling  progran  to 

—  use  this  sort.  To  uso  tho  sort 

—  execute  the  first  procedure 

—  described  below,  Then  execute  tho 

—  second  procedure  described  below. 

—  The  clement  in  tho  second 

—  procedure  will  bo  received  in 

—  sorted  order. 

—  Tho  first  procedure  should  make 

—  entries  into  the  task  at  Send  with 

—  the  first  through  the  next  to  the 

—  last  elements  in  the  external 


—  data  structure  for  tho  Element 

—  parameter  and  a  value  false  for 

—  the  Laat^Itea  parameter.  Finally, 

—  an  entry  should  be  made  into  the 

—  task  at  Send  with  the  last  value 

—  in  the  external  data  structure  for 

—  the  Element  parameter  and  with  a 

—  value  of  true  for  tho 
—  Last_Elcmcnt  parameter. 

—  The  second  procedure  should  make 

—  consecutive  entries  into  the 

—  task  at  Receive  expecting  the 

—  first  through  next  to  last  sorted 

—  elements  from  tho  Element 

—  parameter  and  false  for  the 
—  Last_Itca  parameter  each  time. 

—  With  the  last  entry  into  tho 

—  task  at  Receive  the  last  sorted 

—  item  in  the  internal  data 

—  structure  will  be  returned 

—  in  Element  and  the  parameter 
—  Last„Klement  will  be  true. 

end  Transfer  : 
end  Sort_Packogo  } 

notice  that  ListJType  and 
Nunbcr„or_Elcmcnt  parameters  ore  not 
present.  “That  is  because  in  thl3  case 
the  generic  package  needs  to  know  nothing 
about  tho  external  data  structure  because 
no  references  are  made  to  it  from  within 
the  generic  package  itsolf.  Ml  elements 
will  be  removed  from  the  data  structure 
and  given  to  tho  sort  package  through  tho 
interface  task.  Two  procedures  must  be 
written,  by  a  programmer  using  the 
package,  to  interface  with  tho  tasks. 

All  nocossary  references  to  the  external 
data  structure  con  be  made  within  these 
external  procedures.  Examples  of  tho 
externa)  procedures  used  to  sort  an  array 
through  ^.ia  uso  of  an  intarfaco  task 
might  resemble  those  two  procedures. 

procedure  Send 

(  List  :  in  List_type  )  is 
begin 

for  Index  in  1. .List_Typo' Last-1  loop 
Sort_Packago.  SortT  Send 
(  List  (  Index  ),  false  ); 

end  loop  ; 

Sort_Package.  Sort.  Send 

(  List  (  Listjrypo'Last  ),  true  ); 
end  Send; 

procedure  Receive 

(  List  :  out  ListJTypo  )  is 

Last_Iten  :  Boolean”; 
begin 

for  Index  in  List_Ty pc' Range  loop 
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SortJ’ackage.  Sort.  Receive 

(  Cist  (  Index  ),  Lnst_Xtca  ); 
end  loop  j 
end  Receive: 

These  tvo  procedures  follow  the 
intuitive  mothod  of  preforming  tt  sort 
very  closely  end  they  are  very  simple  to 
implement.  It  is  important  to  note  that 
these  procedures  nre  not  included  as 
generic  formal  subprograms.  Therefore, 
the  generic  package  specification  should 
contain  documentation  explicitly  stating 
that  two  procedures  similar  to  the  above 
must  be  used  with  the  generic  package  and 
it  should  provide  specific  directions 
relating  to  operation  of  each  of  these 
procedures.  This  solution,  using 
tasking,  seems  to  be  simple  and  effective 
enough  so  that  anyone  with  a  basic 
understanding  of  tasking  could  have  the 
generic  package  working  very  quickly. 
However,  if  consideration  Is  given  to 
those  who  do  not  have  a  basic  knowledge 
of  tasking  or  to  those  projects  which  do 
not  allow  tasking,  on  alternate  solution 
must  be  developed. 

If  the  use  of  tasking  is 
restricted,  then  any  solution  that  may  be 
developed  is  likely  to  suffer  the  sane 
faults  as  did  the  previous  examples. 
Consequently,  to  create  an  effective 
solution,  a  different  approach  to 
generics  must  be  taken.  This  new 
approach  will  start  at  the  beginning  with 
roconsldering  the  general  principle 
behind  generics.  Basically,  the  question 
that  must  be  answered  is,  MiIow  generic 
should  generics  be?"  Generally,  teaching 
and  litercture  suggest  that  generics 
should  provide  abstraction  from  data. 

The  previous  examples  provided  complete 
abstraction  from  both  tho  external  data 
structure  and  tho  data  to  be  sorted,  but 
at  a  price. 

Maintaining  this  extra  capability  of 
tho  generic  unit  requires  the  addition  of 
several  generic  formal  parameters,  or 
some  other  method  of  interface  between 
the  generic  unit  and  the  calling  unit. 
Keeping  this  in  mind  the  question,  "is 
comploto  abstraction  from  tho  external 
data  structure  necessary  or  even 
advisable?",  must  bo  asked. 

In  the  above  enso  of  the  sort, 
abstraction  fron  only  the  data  to  be 
sorted  seems  to  be  enough.  Certainly, 
individual  generic  units  will  have  to  be 
developed  to  work  with  different  types  of 
list  data  structures  if  a  complete 


solution  is  to  be  added  to  any  library. 

In  particular  a  slightly  different 
generic  unit  would  hove  to  be  developed 
for  arrays,  linked  lists,  and  other  types 
of  data  structures.  This  is  a  small 
price  to  pay  for  having  a  generic  unit 
that  is  simple  and  encourages  its  use. 

For  example,  tho  generic  unit  for  sorting 
arrays  with  elenonta  of  any  abstract  type 
could  be  as  simple  as  this  genoric. 

generic 

typo  Elementjrype  is  private  ; 

with  function  "<" 

(  Element_l  :  ElemontJTypo  ; 

Elcment_2  :  Element_typo  ) 
return  Boolonn  ; 

procedure  Sort  (  List:  in  out  LlstJTypo); 

In  this  case  no  method  of 
transferring  data  to  and  fron  tho  genoric 
unit  is  necessary  since  tho  external  data 
structure  is  visible  to  the  generic  unit. 
Therefore,  the  array  can  be  manipulated 
directly  by  tho  generic.  This  is  clearly 
tho  simplest  way  to  implement  a  generic 
sort  providing  that  the  data  to  bo  sorted 
is  contained  within  an  array. 

?ho  generic  sorting  of  linked  lists 
is  not  quito  as  simple.  This  is  due  to 
the  fact  that  there  is  no  standard  format 
for  linked  list.  However,  if  during  the 
development  of  a  particular  application  a 
sorted  linked  list  is  required,  looking 
at  the  specification  of  the  generic 
linkod  list  sort  and  forming  tho  linked 
list  as  proscribed  by  the  genoric  unit 
will  be  a  simple  task.  In  any  case 
following  the  fron  of  tho  linked  list 
imposed  by  tho  generic  for  tho  sorting  of 
a  linked  list  will  bo  much  easier  than 
developing  several  confusing  goneric 
formal  subunits  required  to  use  a 
completely  abstracted  generic.  On  tho 
other  hand,  a  complete  solution  night  be 
to  contain  the  generic  sort  within  a 
generic  package  for  linked  list 
operations  in  which  tho  dosign  of  tho 
linked  list  would  bo  Know  ooforo  hand. 

An  example  of  a  specification  for  a 
genoric  sort  of  a  linked  list  night  look 
similar  to  this: 

generic 

typo  Elencntjrype  is  private  ; 

with  function  "<" 

(  Element  :  Elenent_Typo  ; 
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Elcnant  :  Eloncnt_Typo  ) 
return  Boolean  : 

—  Individual  nodes  of  the  linked  list 

—  nust  take  the  fern 

—  record 

Elenent  :  Elonencjrypo  ; 

—  Next  :  Listjrype  : 
end  record  ; 

—  where  Elenentjrypc  can  be  any  typo 

—  excluding  task  typos  and  constants. 

—  Listjrypo  pust  be  a  pointer  to  this 

—  record. 

procedure  Sort  (  Lists  in  out  LlatJTypo); 

The  different  approach  token  to 
design  theso  last  two  gonerics  is  a  very 
significant  one.  If  an  attonpt  is  node 
to  nako  generic'  units  too  gcnaric,  they 
nay  beconc  quite  difficult  to  use. 
However,  by  narrowing  the  scope  of 
genoric  units  so  that  it  abstracts  fron 
only  certain  olcnonts  will  produce 
results  that  are  nuch  noro  likely  to 
facilitate  usa. 

Two  different  approaches  to  gonerics 
have  been  given  hero.  For  oach  approach 
to  designing  a  particular  generic  unit 
exanplcs  have  boon  given  of  ways  to 
inplonont  each  approach.  The  basic 
principles  behind  naking  each  oxnnplc 
noro  usable  aro  applicable  to  the 
devolopnent  of  any  generic  unit,  and  they 
aro: 

1.  The  nunbor  of  gonoric  fornal 
paranoters  should  bo  United  to  the 
snallost  nunbor  possible. 

2.  Each  rcnainlng  genoric  fornal 
subunit  should  be  as  easy  as 
possible  to  understand  and  code. 

3.  If  the  gonoric  unit  designed  undor 
the  principle  of  total  abstraction 
fron  data  produces  hard  to  use 
gonoric  fornal  subprograns, 
redesign  the  genoric  unit  with 
decreased  genoric  abstraction. 

4.  Lastly,  of  course  docunont  every 
aspect  of  the  necessary  gonoric 
fornal  paranoters.  In  addition,  ns 
with  the  tasking  exanplo, 
explicitly  docunent  any  necessary 
clcncnts  that  do  not  appear  in  the 
genoric  specification.  Provide 
exanples  if  necessary. 


In  short,  the  designer  of  a  generic 
nust  insure  that  tho  tine  spent,  by  a 
progranner,  to  understand  how  to  use  n 
generic  unit  nu3t  be  substantially  less 
than  the  tino  required  by  that  progranner 
to  inplenont  a  non-generic  solution  to 
tho  problen.  Methods  such  os  wore 
described  in  this  papor  will  ensure  that 
this  requirenent  is  net. 

The  purpose  of  generics  is 
eventually  to  provide  a  largo  librory  of 
re-usable  code.  If  this  goal  is  to  be 
realized,  then  groat  care  nust  bo  taken 
to  ensure  that  each  genoric  unit  placed 
In  these  libraries  is  easy  enough  to  uso 
so  that  people  will  KOQ&  to  use  then.  If 
theso  precautions  are  not  taken,  one  of 
tho  nain  goals  of  Ada  nay  not  bocono  a 
reality. 
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Abac  race.  Byzantine  Agreement  Prococola 
Involve  che  execution  of  conaenaua 
algorlthr-j  co  agree  on  che  value  aenc  by  a 
transmitter  in  a  distributed  processing 
system  in  which  .none  of  che  proceaaors  may 
fail  in  arbitrary  and  poaaibly  malicious 
waya.  This  paper  preaenca  deaign 
considerations  involved  in  an  attempt  to 
uae  cheae  prococola  within  ADA  intertask 
communication  aa  a  mechanism  to  aupporc  the 
deaign  of  fault  tolerant  systems. 


JL _ INTRODt’CTIOH 

The  Byzantine  General' a  Problem  waa 
Introduced  by  Lamport,  Shoatak  and  Peaae.6 
It  ia  a  problem  Involving  N  proceaaora  in  a 
diatributed  environment  chat  exchange 
meaaagea  to  reach  agreement  on  a  value  aent 
by  one  of  them  (called  the  tranamitter) . 
In  an  ideal  failure-free  ayatem  chia  would 
poae  no  problem.  However,  in  an 
environment  where  proceaaora  may  fail,  it 
becomea  of  fundamental  concern  in 
guaranteeing  correctness  of  proceaaing 
results. 

Byzantine  agreement  protocols  have 
been  introduced  to  solve  the  problem.  A 
majority  of  the  protocols  deal  with  the 
execution  of  consensus  algorithms  to  reach 
agreement  on  a  transmitted  value  having  a 
binary  domain  though  there  are 
modifications  to  the  algorithms  that  allow 
the  domain  to  be  of  any  size.7  When  the 
algorithms  are  executed,  rounds  of  messages 
are  exchanged  over  a  reliable  communication 
system  such  that  no  messages  are  lost  or 
modified.  The  sender  of  any  message  i3 
always  identifiable.  All  the  protocols 
satisfy  the  following  two  conditions: 

(i)  If  the  transmitter  is  correct  and 
transmits  value  v  then  all  correct 
processors  must  agree  on  v  . 

(ii)  All  correct  processors  must  agree  on 
the  same  value. 

Variations  on  the  protocols  exist  in 
the  literature.  Some  of  the  algorithms  are 
d e  t  e  r mi  n  i  s  t  i  c  ^  while  others  are 


probabilistic. 2  The  algorithms  can  bo 
further  divided  based  on  the  environment  of 
operation  which  can  be  synchronous®  or 
asynchronous.1  In  the  completely 
asynchronous  case  where  there  is  an  unknown 
bound  on  message  delivery  time,  processor 
drift  time  and  message  order  not 
guaranteed,  it  has  been  shown  by  Fischer, 
Lynch  and  PAterson  chat  no  deterministic 
algorithm  exists  to  tolerate  even  one 
failed  processor.!* 

Algorithms  can  also  be  viewed  based  on 
the  types  of  failures  they  will  tolerate. 
The  most  severe  failure  is  when  faulty 
processors,  also  known  as  traitors,  can 
send  spurious  messages  Including  forging  of 
Information  relayed  from  correct 
processors.  This  typo  of  failure  is  known 
os  "Byzantine  Failure."  Authenticated 
Byzantine  Failure  can  occur  when  messages 
choc  are  relayed  contain  unforgeable 
signatures  of  the  relaying  processors.  In 
this  case,  a  message  that  contains  the 
signature  of  at  least  one  correct  processor 
can  be  assumed  to  be  accurate.  This  limits 
che  damage  a  faulty  processor  can 
accomplish.4  Omission  failures  are 
failures  where  the  faulty  processor  falls 
co  relay  some  of  the  messages.  The 
simplest  failure  is  known  as  "fail-stop" 
where  processors  simply  stop  participating 
in  the  algorithm. 

The  number  of  faulty  processors  that 
an  algorithm  can  tolerate  and  still  meet 
the  two  conditions  is  closely  associated 
with  the  type  of  failure  possible.  This 
paper  will  focus  on  algorithms  that 
tolerate  "Byzantine  Failures."  In  order 
for  the  correctness  of  the  protocol  to  be 
insured,  it  has  been  shown  that  the  number 
of  traitorous  processors  must  be  less  than 
one  third  of  the  total  number  of  processors 
participating  in  the  protocol.® 

ADA  provides  a  mechanism  for  inter¬ 
task  communication  through  the  rendezvous. 
ADA  also  provides  facilities  to  handle 
specific  cases  of  failure  of  an  attempted 
rendezvous.  Some  of  these  include 
selective  accepts,  delay  and  exception 
handlers  to  handle  tasking  error 
exceptions.  For  fault  tolerant 


218  7th  Annual  National  Conference  on  Ada  Technology  1989 


distributed  systems  programmed  in  AOA  the 
loss  of  an  individual  processor  must  not 
result  in  system  failure. 

The  purpose  of  this  paper  is  to 
present  an  attempt  to  use  Byzantine 
protocols  to  enhance  the  features  provided 
by  ADA  intertask  communication  in  the 
design  of  fault  tolerant  systems. 

?  PESTC>>  ISSUES 

One  approach  to  implementing  Byzantine 
agreement  as  a  facet  of  intertask 
communication  assumed  the  communicating 
parties  to  be  operating  in  the  same 
environment.  This  allowed  one  to  focus  on 
the  algorithm  and  the  communication 
necessary  to  achieve  Byzantine  agreement. 
In  this  manner  a  coupling  of  the  agreement 
protocols  and  the  communication  protocols 
necessary  for  agreement  resulted.  The 
communicating  parties  were  not  strongly 
connected  to  the  agreement  protocols  that 
were  executing  on  their  behalf  and  would 
therefore  have  little  Influence  on  protocol 
execution  except  for  the  initial  value 
transmitted.  Since  the  protocols  were 
executing  on  behalf  of  the  communicating 
parties,  it  was  felt  chat  a  stronger  tie 
between  the  two  was  desirable.  As  a  result 
a  design  evolved  that  had  the  communicating 
parties  more  tightly  coupled  to  the 
algorithms.  The  algorithms  were  also 
connected  to  the  communication  protocols 
needed  to  carry  them  out. 

The  greatest  flexibility  was  achieved 
when  the  algorithm  and  the  communicating 
parties  were  strongly  connected  and  the 
method  of  communication  was  supplied  by  the 
communicating  parties.  This  allowed  for 
the  algorithm  to  be  used  to  achieve 
agreement  even  when  the  communicating 
parties  were  in  different  environments 
assuming  that  the  communicating  parties 
handle  the  inter-  environment  communication 
protocols  and  the  Byzantine  protocols  focus 
on  reaching  agreement  utilizing  the 
communication  protocols  supplied. 

The  rc3t  of  the  paper  focuses  on  the 
progression  of  design  issues  arising  from 
the  loosening  of  the  connection  between  the 
agreement  and  communication  protocols  and 
the  strengthening  of  the  connection  between 
the  agreement  protocols  and  the 
communicating  parties  on  whose  behalf  they 
are  being  executed. 

In  order  to  provide  Byzantine 
agreement  as  a  reusable  piece  of  software 
the  ADA  package  was  chosen  as  the  best 
means  of  providing  the  protocol  and  all  the 
services  needed  for  utilization  of  the 
protocol.  Also  since  flexibility  in  the 
number  of  communicating  parties 
henceforth  known  as  users  -  was  important  a 
generic  package  importing  the  number  of 


users  became  the  basis  of  all  the  designs. 
The  protocols  are  executed  by  processes 
that  exchange  messages  for  the  purpose  of 
reaching  agreement,  for  this  reason  the 
code  implementing  the  algorithm  is  provided 
by  tasks  which  have  the  ability  to 
rendezvous  and  can  thereby  exchange 
messages.  The  degree  of  coupling  results 
from  the  method  of  task  declaration  and 
package  Instantiation.  The  tighter  the 
coupling,  the  greater  the  affect  the  user 
has  on  algorithm  execution  and  termination. 


JL _ EES  mi ,  PFOGRESSICU 

Coupled.  Agreement  and  Connunleac Ion 
RflCkaafu.  The  first  design  explored  Is  a 
package  generic  on  the  number  of  users  (N) . 
It  contains  H  identical  tasks  where  each 
task  includes  code  for  the  Byzantine 
agreement  algorithm.  In  addition  the 
package  provides  the  user  with  the 
capability  of  registering  and  receiving  an 
ID  for  one  of  the  M  tasks  responsible  fo^ 
the  execution  of  the  protocol  on  his 
behalf. 

The  package  allows  the  user  to  start 
the  protocol  with  an  initial  value  which  is 
passed  to  the  Byzantine  agreement  task  that 
corresponds  to  the  ID  supplied  by  the  user. 
Once  agreement  is  reached  the  user  can 
retrieve  the  committed  value  by  calling  a 
procedure  provided  by  the  package. 

The  package  will  be  used  as  follows: 
The  package  is  instantiated  with  a  specific 
value  for  M  (greater  chan  four) .  Each  of 
the  N  users  register  and  is  returned  an  ID 
of  a  Byzantine  agreement  task  that  became 
active  when  the  package  was  instantiated. 
The  cask  is  responsible  for  executing  the 
agreement  algorithm  on  the  user's  behalf. 
A  user  wishing  to  transmit  a  value  starts 
the  protocol  passing  the  value  to  the 
package.  Once  started,  the  Byzantine  tasks 
execute  the  algorithm  exchanging  rounds  of 
messages  between  each  other  until  all  tasks 
commit.  The  user  then  calls  for  the 
committed  value.  The  general  design 
concept  is  illustrated  in  figure  la  with 
package  detail  illustrated  in  figure  lb. 


It  is  interesting  to  note  chat  since 
all  the  Byzantine  tasks  are  declared  within 
the  package  they  can  rendezvous  with  each 
ocher  to  accomplish  the  sending  and 
receiving  of  messages  necessary  to  reach 
agreement.  To  prevent  deadlock  transport 
tasks  can  be  used  a3  intermediaries  in  the 
process  of  sending  the  messages.  It  is 
also  possible  to  prevent  deadlock  through 
the  use  of  buffers.  All  the  users  must  be 
declared  within  the  same  environment,  the 
one  that  instantiates  the  package. 

The  first  approach  has  certain 
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deficiencies  arising  from  the  eight 
coupling  of  the  agreement  and  communication 
protocols  and  the  loose  connection  with  the 
user  of  the  package.  The  concept  of  a 
traitorous  user  is  difficult  to  understand 
due  to  the  fact  that  the  user  will  not 
Influence  the  content  of  the  messages 
exchanged  onee  the  initial  value  is 
transmitted  because  all  the  communication 
occurs  within  the  package  between  the  tasks 
there.  If  one  of  the  users  should 
terminate  it  will  not  affect  the  Byzantine 
agreement  casks  since  they  are  declared 
within  the  package.  This  might  not  be 
appropriate  since  the  Byzantine  casks  are 
executing  the  protocol  on  behalf  of  the 
use...  In  order  for  the  package  to  be  used 
by  users  operating  in  different 
environments  additional  support  is 
necessary  to  provide  the  inter-environment 
communication  needed. 


FiS.  1A 


package  goneric  on  H  chat  offers  the  user  a 
Byzantine  task  type  that  contains  the 
algorithm  to  be  executed  to  reach 
agreement.  This  gives  the  user  the  ability 
to  declare  objecta  of  this  type.  It  also 
results  in  a  tighter  coupling  between  the 
user  and  the  agreement  protocol  executing 
on  ita  behalf.  The  taak  objects  once 
created  must  register  in  order  for  the 
package  to  know  how  many  users  are  actually 
utilising  its  services.  The  package  will 
have  to  provide  the  tasks  some  means  of 
sending  and  receiving  messages  since  they 
are  unaware  of  each  ocher  and  therefore 
cannot  rendesvous  to  exchange  messages. 
Because  of  this  the  package  has  to  provide 
a  method  of  buffering  the  messages  after 
the  send  operation  and  until  they  can  bn 
retrieved.  It  is  also  necessary  for  the 
package  to  provide  a  service  enabling  the 
user  to  start  the  protocol  with  an  initial 
value.  Once  the  protocol  completes  and  the 
casks  commit  the  user  con  retrieve  the 
committed  value  from  the  task. 

Use  of  the  package  la  described  by  the 
following.  The  package  is  Instantiated 
with  a  value  for  N.  Users  in  the 
environment  instantiating  the  package  can 
declare  up  to  N  Byzantine  task  objects  of 
the  cask  type  provided  by  the  package 
interface.  Once  created,  the  task  objects 
rogister  and  wait  for  the  protocol  to 
start.  One  of  the  users  starts  the 
protocol  with  an  Initial  value.  The  task 
objects  exchange  messages  using  the 
send/receive  services  provided.  These 
services  allow  access  to  the  buffered 
messages  within  the  package.  Once  the 
tasks  commit  the  user  retrieves  the 
committed  value  from  the  task  object, 
figure  2a  illustrates  this  design  concept. 


some  of  the  conditions  resulting  from  the  that  result  from  the  tighter  coupling 

first  design  a  second  approach  utilizes  a  between  the  user  and  the  Byzantine  tasks 
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have  co  be  emphasized.-  Owing  to  the  fact 
that  the  user  has  the  ability  c©  declare 
objects  of  the  Byzantine  task  type,  the 
task  becomes  dependent  ©n  the  user  and  the 
user's  behavier  can  influence  the  task  such 
chat  if  the  user  is  aborted  the  task  will 
be  aborted  also.  This  is  not  a  deficiency 
since  the  cask  is  executing  on  behalf  ©f 
the  user.  However,  even  chough  there  is  a 
tighter  coupling  between  the  user  and  the 
agreement  protocols  there  is  still  a  strong 
coupling  between  the  agreement  and 
communication  protocols.  The  send/receive 
operations  are  provided  by  the  package  and 
the  user  still  has  little  Influence  on  the 
messages  transmitted  in  the  various  rounds 
of  message  exchange.  Also  by  providing 
the  cask  type  in  the  package  interface  the 
user  creates  tasks  that  execute  the 
Byzantine  agreement  protocol  with  the 
package  providing  the  communication.  Thl3 
leads  to  an  emphasis  on  the  communication 
services  of  the  package  rather  than  the 
agreement  protocol.  This  is  seen  in  figure 
2b  which  illustrates  the  package  details. 


FIG.  2b 

Ualng...p.aintcra_f or  Byxant Ine _ tasks... 

An  interesting  ramification  of  tne 
preceding  design  occurs  when  the  package 
provides  pointers  for  the  Byzantine  task. 
Using  pointers  allows  the  Byzantine  tasks 
to  be  dynamically  created.  When  the 
protocol  starts  up,  the  Byzantine  tasks  are 
passed  the  pointers  of  all  the  dynamic 
task3  participating  in  the  protocol.  The 
pointers  can  then  be  used  by  the  tasks  to 
rendezvous  for  the  purpose  of  sending  and 
receiving  messages.  Having  pointers 
loosens  the  connection  between  the  user  and 


the  Byzantine  casks.  This  results  fr©m  the 
fact  the  allocator  Is  offered  through  the 
package  interface  and  objects  dynamically 
created  are  dependent  en  the  package  not 
the  creator  of  the  object. 

Tnporrfd  eeagiifi  1  cat  ion  „  The  last 
design  considered  offers  a  tight  coupl’ng 
between  the  user  and  the  agreement 
protocols.  This  Is  accomplished  utilizing 
a  generic  package  that  imports  a  discrete 
range  of  local  IDs  to  be  used  by  the 
package  co  differentiate  the  various 
participants,  a  specific  ID  within  the 
range  to  designate  the  Byzantine  task 
provided  by  the  package  and  a  send 
operation  to  be  used  by  the  Dyzantlne 
agreement  task  when  sending  messages.  The 
send  operation  provided  by  the  user  is 
responsible  for  possible  reformatting  of 
the  message  supplied  by  the  package  to 
conform  to  the  format  expected  by  the 
communication  protocols  as  well  as  possible 
translation  of  the  local  IDs  used  in  the 
package  to  IDs  used  by  the  communication 
protocols  to  designate  the  various 
communicators.  The  send  operation  must 
therefore  handle  messages  of  a  particular 
message  type.  Two  approaches  co  the 
message  type  are  possible.  One  is  co 
declare  the  message  type  as  part  of  the 
package  and  the  user  must  supply  a  send 
operation  capable  of  handling  messages  of 
that  type.  The  ocher  approach  is  to  Import 
a  private  message  type.  To  allow  the 
Byzantine  task  the  capability  of  forming 
messages  which  is  an  integral  part  of  the 
agreement  algorithm,  the  user  must  also 
provide  a  routine  to  construct  the  message 
into  the  appropriate  type  using  Information 
supplied  by  the  Byzantine  task.  Once 
formed  the  message  is  then  transmitted 
using  the  send  operation  supplied  by  the 
user. 

The  package  in  addition  provides  a 
service  that  allows  the  Byzantine  agreement 
task  to  receive  messages  from  the  user  and 
a  start  protocol  procedure  that  enables  the 
user  to  start  the  protocol  with  a  specific 
value.  It  also  provides  a  commit  routine 
chat  the  user  can  call  to  retrieve  the 
committed  value  from  the  Byzantine  task. 

Package  use  is  illustrated  by  the 
following.  Each  user  instantiates  the 
package  supplying  a  range  of  participating 
IDs,  a  specific  IC  that  i3  within  the  range 
to  be  used  to  identify  the  Byzantine  task 
contained  in  the  package  and  a  send 
procedure.  The  tB3k  in  the  package  becomes 
active  upon  instantiation  and  waits  for  a 
user  to  start  the  protocol.  Once  started, 
the  task  sends  messages  using  the  send 
procedure  supplied  by  the  user  and  receives 
messages  from  the  user.  It  is  the 
responsibility  of  the  user  to  relay 
messages  from  the  other  participants.  Once 
the  task  commits  the  user  retrieves  the 
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committed  value  from  the  package.  This  Is 
depleted  In  figure  3a  with  the  package 
details  highlighted  in  figure  3b. 


FIG.  3A 


FIG.  3b 

This  design  offers  the  greatest 
flexibility  in  terras  of  package  use.  Due 
to  the  tight  coupling  between  the  user  and 
the  agreement  protocols  fail-stop  failures 
can  occur  whenever  a  user  is  aborted  or 
terminates  since  the  package  instantiated 
by  the  user  is  affected  also.  However, 
because  comraunicrtion  is  supplied  by  the 
user,  Byzantine  ’'failures  are  also  possible 
since  the  user  intercepts  all  messages  sent 
and  received  by  the  package.  This  gives 
the  user  the  capability  to  forge  any 
message.  This  package  can  also  be  utilized 
by  users  operating  in  different 
environments  since  it  is  up  to  the  user  to 
supply  the  necessary  inter-environment 
communication  protocols  to  the  generic 
package. 


The  package  can  be  used  to  provide  a 
synchronous  or  an  asynchronous  protocol. 
This  depends  on  the  algorithm  the  Byzantine 
agreement  cask  In  the  package  contains.  A 
synchronous  algorithm  assumes  the 
communication  network  is  synchronous.  It 
is  the  responsibility  of  the  communication 
network  that  the  user  provides  to 
synchronize  message  rounds  within  the 
package  through  the  user.  A  package 
supplying  a  synchronous  algorithm  will  have 
to  contain  a  service  to  advance  to  the  next 
round  that  the  user  can  call  when  necessary 
to  synchronize  message  rounds  based  on 
information  from  the  communication  network. 

4.  CQMCLUSIOHS 

Byzantine  agreement  protocols  provide 
an  important  service  in  distributed 
processing  guaranteeing  correctness  of 
processing  results.  In  utilizing  them  as 
part  of  ADA  intertask  communication  one  can 
improve  on  the  reliability  of  message 
communication  in  multi-task  processing.  By 
utilizing  a  package  that  has  a  tight 
coupling  between  the  user  and  the  agreement 
protocols  with  the  user  supplying  the 
communication  protocols  the  greatest 
flexibility  can  be  achieved  in  terms  of  the 
operating  environment  and  type  of  algorithm 
offered. 
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The  ADVISOR  Is  an  expert  svstea  designed 
to  automate  and  facilitate  the  dudes  of  a 
student's  academic  advisor  within  a  college 
or  university.  This  system,  written  In  LIST, 
has  the  capability  to  dlreet  students  In 
selecting  required  courses  that  are  available 
In  their  curriculum.  It  also  checks  for 
courses  thac  have  prerequisites  and  corequi¬ 
sites  to  ensure  that  they  have  been  taken 
prior  to  or  will  be  taken  simultaneously  with 
the  courses  requested.  The  purpose  of  this 
paper  Is  to  discuss  the  problems  encountered 
when  converting  a  LISP  prototype  to  a  system 
written  In  Ada. 


INTRODUCTION 

A  prototype  Is  usually  a  quickly  built  system 
chat  performs  part  or  all  of  the  functions  desired 
from  a  specific  software.  Converting  a  prototype 
to  a  working  svsten  In  Ada  from  any  software 
presents  a  number  of  problems.  The  prototype  may 
be  too  slow,  too  large,  and/or  awkward  to  use,  due 
primarily  to  Its  quick  design.  Also,  some  funct¬ 
ions  that  are  supported  by  a  prototyping  language 
may  not  be  supported  by  Ada.  When  analysing  some 
of  the  characteristics  of  a  prototype  and  the 
differences  between  a  specialized  language  and  a 
general-purpose  high  level  language  one  must 
confront  these  problems. 

The  ADVISOR*  prototype  Is  a  rule  based  expert 
system  which  accepts  a  student's  Identification 
number  and  returns  a  list  of  courses  which  the 
student  Is  eligible  to  take  at  time  cine.  The 
prototype  requires  the  actual  code  nnd  four  rule/ 
database  files.  The  prototype  runs  within  a  LISP 
environment,  thus  performance  is  slow  due  to  the 
interpretive  nature  of  LISP. 

We  were  assigned  the  task  of  converting  the 
ADVISOR  prototype  to  Ada  In  our  software  design/ 


development  course.  During  the  conversion  process, 
we  encountered  the  following  problems:  (1)  deter¬ 
mining  how  to  incorporate  the  prototype  into  a 
software  development  paradigm,  (2)  determining  when 
to  emulate  prototype  constructs  or  when  to  redesign 
them  for  efficiency  and  (3)  to  follow  good  soft¬ 
ware  design  practices. 

INCORPORATION  OF  THE.  PROTOTVPF. 

Typically  software  design  projects  are  done 
in  the  following  manner:  Systems  Engineering, 
which  entails  determining  all  resources  required 
at  the  system  level;  Software  Requirement  Develop¬ 
ment,  which  determines  all  software  functions;  and 
Design,  which  describes  software  architecture  and 
procedure  to  a  level  of  detail  suitable  to  be  used 
for  coding,  testing,  and  maintenance.  This 
procedure  Is  commonly  referred  to  as  the  "Classical 
Life  Cycle  Paradigm."* 

The  prototyping  process  typically  transpires 
as  follows:  Definition  of  the  objectives  for  the 
software  project;  Identification  of  known  require¬ 
ments;  Development  of  an  abbreviated  design;  and 
Building  the  prototype.  Tills  process  is  continued 
until  the  prototype  Is  completed.4  After  the 
prototype  has  been  built,  It  can  be  used  as  the 
finished  produce  or  It  can  be  used  to  aid  In  the 
development  of  the  product  In  another  language. 

Our  problem  entailed  the  Incorporation  of  the 
complete  prototype  within  the  classical  life  cycle 
paradigm.  We  had  to  first  decide  If  the  prototype 
could  serve  as  a  complete  requirement*  specifics- 
tion.  The  problems  encountered  in  the  process 
forced  us  to  create  a  requirement*  specification 
based  on  the  prototype.  Some  of  the  problems  were 
caused  by  lack  of  complete  understanding  of  proto¬ 
type  operation,  and  a  poor  knowledge  of  LISP. 
Another  problem  was  encountered  because  the  proto¬ 
type  Itself  existed)  The  tendency  was  to  under¬ 
estimate  the  effort  required  to  develop  a  complete 
and  accurate  requirements  specification  because  It 
seemed  that  so  much  of  the  work  was  already  done. 
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D ETA t LEO  DES16S 

The  basic  0«a  structure  in  LISP  Is  the 
list.  Therefore,  a  decision  whether  to 
emulate  LISP  constructs  or  to  rewrite  then 
utilising  the  features  within  Ada  had  to  be 
made.  We  chose  a  combination  of  the  two.  the 
list  constructs  were  logically  the  optimum  way 
to  structure  some  of  the  run-tiae  data,  hut 
the  flexibility  of  other  data  structures 
(l.e.  trees,  queues,  etc.)  provided  more 
efficient  processing.  Several  problems 
resulted  because  of  the  above  coablnatlen. 

Since  the  coding  was  to  he  accomplished 
using  the  Ada  programing  language,  the  deci¬ 
sion  was  aade  to  create  detailed  design 
document*  aligned  with  Ada  concepts.  Ada  is  a 
strongly  typed  language  which  restricts  coer¬ 
cion,  whereas  LISP  does  not  restrict  Mixing 
data  types.  LISP  facilitated  rapid  development 
of  the  prototype  because  little  attention  had 
to  he -given  to  the  actual  data  types  being 
processed.  Using  Ada  to  write  the  AhVISQR 
system  required  specialised  packages  to  create 
and  manipulate  binary  tree  structures,  llnked- 
11st  structures,  and  queues.  The  rule  bases 
had  to  be  completely  rewritten  in  ordei  to  be 
utilised  efficiently  In  Ada. 

Since  the  prototype  written  in  LTSP  used 
recursion  extensively,  several  decisions  had  to 
be  made  In  the  design  process.  We  bad  many 
problems  trying  to  ascertain  when  recursion  was 
suitable  for  use  In  Ada. 

Although  the  existence  of  the  prototype  was 
beneficial  to  us  during  the  development  of  the 
requirements,  It  was  somewhat  detrimental  during 
the  design  phase.  Initially  not  enough 
attention  was  given  to  the  development  of  the 
data  structures  and  the  Internal  processing  of 
the  system.  Consequently,  we  had  to  redesign 
the  system  several  times.  Care  must  be  taken 
not  to  rely  too  much  on  the  prototype  during  the 
detailed  design  phase. 

Once  the  detailed  design  was  completed,  we 
began  coding  the  system.  The  biggest  problem 
we  encountered  was  one  of  Interfacing  the 


modules.  The  lists,  and  msnv  of  the  variables 
In  the  prototype,  wore  global.  Ve  had  overlooked 
these  factors  during  the  design  phase.  This 
oversight  resulted  In  disaster  during  integration 
testing,  thus  necessitating  a  redesign  of  the 
system. 

SUHKAXV 

Utilising  a  LISP  prototype  to  develop  a 
software  package  can  cause  manv  problems.  This 
Is  particularly  true  when  the  target  language 
is  as  strongly  typed  as  Ada.  The  major  diffi¬ 
culties  we  encountered  were  the  lack  of  structure 
and  the  ease  of  list  processing  afforded  by  the 
LISP  language.  The  faet  that  we  had  a  completely 
working  prototype  caused  us  to  attempt  to  emulate 
coo  many  of  Its  features  without  full  considera¬ 
tion  to  the  eventual  Ada  implementation.  When 
working  from  a  prototype,  designers  should  be 
cognisant  of  these  pitfalls.  Such  errors  are 
more  prevalent  when  using  the  Ada  programming 
language  because  of  the  rigid  enforcement  of 
structured  program  development  methodologies. 
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An  Implementation  o t  the  Standard  Math  functions  in  Ada 


James  Anthony  T rush 


Tha  University  of  Mississippi 


ABSTRACT 

The  ADA  programming  language 
provides  excellent  capabilities  for 
writing  highly  structured,  reliable, 
reusable  and  easily  aaintainabla 
applications.  However,  in  order  for  ADA 
to  be  acceptable  and  usable  to  engineers 
and  other  scientists,  certain  basic 
mathematical  functions,  generally 
provided  as  math  libraries  with  other 
languages,  must  bo  Bade  available, 
reliable,  and  easily  usable.  The 
purpose  of  this  project  was  to  sake 
available  a  generic  packaga  of  nath 
functions  with  enough  accuracy  and 
efficiency  to  encourage  the  use  of  ADA 
by  engineers  and  other  scientists  at  the 
University  of  Mississippi,  it  is  also 
hoped  that  the  package  will  encourage 
other  students  to  work  with  ADA  by 
providing  thea  with  challenging  natccial 
on  which  to  base  future  projects. 


OVERVIEW 

The  concept  of  generics  in  ADA  is  a 
powerful  feature  of  the  language.  This, 
coupled  with  other  features  such  as 
strong  typing,  ease  of  nalntenanco,  and 
support  for  parallel  processing  sake  ADA 
superior  to  FORTRAN  for  engineering  and 
scientific  applications.  Tho  project  is 
implemented  as  a  generic  package  of  nath 
functions  so  that  tho  progranner  aay 
instantiate  the  package  for  any 
floating-point  typo.  The  package 
contains  functions  for  tho  conputation 
of  the  following:  Square  root,  cube  root, 
Sine,  Cosine,  Tangent,  Cotangent, 

Natural  Logarithn,  Base  Ton  Logaritha, 
Power,  Exponential,  Arcsine,  Arccosine, 
Arctangent,  Hperbolic  Sine,  Hyporbolic 
Cosine,  and  Hyperbolic  Tangent. 

In  deciding  how  to  implement  this 
package,  several  factors  had  to  be 
considered.  First,  Tho  time  allotted 
for  completion  of  the  project  was 
limited  to  one  semester. 


This  time  constraint  effectively  ruled 
out  starting  from  scratch.  Secondly, 
there  were  two  coapllers  available  for 
the  University  of  Mississippi's 
sainframe. 

The  first  compiler,  the  Telnsoft 
Telegen2  version  1.0/3.05  limits  the 
programmer  to  six  decimal  digits  of 
accuracy  for  floating-point  types.  The 
second,  the  Alsys  IBM  370  ADA  compiler 
for  VM/CMS,  version  2.3,  allows  up  to 
eighteen  decimal  digits  of  accuracy  for 
floating-point  types.  Since  the  primary 
users  of  this  package  are  engineers,  it 
was  necessary  to  provide  the  maximum 
accuracy  possible,  therefore,  the  Alsys 
compiler  was  chosen  to  develop  and  test 
the  package. 

In  order  to  satisfy  tho  time 
constraint,  a  search  for  any 
existing  packages  which  might  satisfy 
the  project's  requirements  was  begun. 
Fortunately,  there  was  a  package  of  math 
routines  available  on  a  tape  containing 
files  from  the  Ada  Software  Repository 
which  met  the  project's  requirements 
precisely. 

The  package  was  writton  in  1982  by 
LCOL  William  Whitaker,  a  member  of  the 
original  High-Order  Languago  Working 
Croup,  and  revised  in  1986  by  LT  Tim 
Eicholz.  The  package  is  an 
implementation  of  the  functions  found  in 
William  Cody  and  William  Waite's 
HSaItv.ftrg-KinuaI..X9r-tht..EleEcnUi:Y. 
Functions".  Prentice  Hall,  1980. 

The  tapes  containing  the  files  from 
the  Ada  Software  Repository  were  in 
DEC-VAX  format  and  had  to  be  translated 
to  IBM  format  to  be  usable.  Using  a 
program  originally  intended  to  perform 
the  translation  from  the  PDP-11  to  IBM 
format,  the  files  containing  the  math 
package  and  test  routines  were  translated 
and  it  was  discovered  that  many  lines 
of  code  were  missing.  These  lines  were 
painstakingly  reconstructed  from  the 
Cody-Waite  manual. 

PRECISION 

The  algorithms  in  the  Cody-Waite 
manual  provide  polynomial  approximations 
that  are  accurate  to  about  eighteen 
decimal  digits.  Since  the  compilers 
available  limit  the  definition  of 
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a  floating-point  type  to  eighteen 
decimal  digits,  tha  Cody-Waite 
approximations  provida  tha  maximum 
accuracy  availabla  at  this  tins. 

As  compilers  allowing  more  than  aightaon 
decimal  digits  become  availabla  to  tha 
Univarsity,  Tha  functions  may  ba  aasily 
modified  to  provida  tha  highar  accuracy. 

In  order  to  undarstand  tha 
pracision  considarations  for  tha 
package,  a  brief  review  of  soaa 
fundamentals  of  floating-point 
representations  in  general,  and  tha 
representations  used  by  tha  IBM  370  in 
particular,  would  ba  helpful. 

Please  keep  in  mind  that  a 
floating-point  number  can  ba  defined  as 
follows: 

SIOM  •  MANTISSA  •  RADIX  ••  EXPONENT 

In  this  representation,  SIGN  is 
either  -1  or  +1,  MANTISSA  is  a 
normalized  fraction, (that  is  tha  first 
digit  following  tha  decimal  point  is  not 
zero) ,  RADIX  is  tha  base  of  tha 
representation,  (i.a.  10  for  decimal,  2 

for  binary,  16  for  hexadecimal,  etc.), 
and  EXPONENT  is  a  positive  or  negative 
integer.  Tha  IBM  370  architecture 
represents  floating-point  numbers  as 
hexadecimal  digits.  In  other  words,  the 
radix  in  the  above  representation  is  IS 
on  the  IBM  370.  Two  other 
considerations  must  be  kept  in  mind  when 
dealing  with  floating-point  numbers  on 
the  IBM  370.  First,  the  exponent  is 
expressed  in  excess  64  notation,  (the 
seven  bit  exponent  is  treated  as  a 
binary  value  and  the  exponent  is  derived 
by  subtracting  64  from  it) .  Second,  IBM 
provides  three  formats  for  representing 
floating-point  numbers,  these  are: 


«>**«- 71  71-117 


The  number  of  decimal  digits 
available  for  a  given  number  of 
hexadecimal  digits  can  be  found  by 
solving  for  X  in  the  following  equality: 

10'  -  16" 
x  -  nlog„  16 

Using  this  equation  it  is  easy  to 
sea  that  for  the  IBM  short  format,  7 
decimal  digits  are  available,  for  the 
long  format  16  decimal  digits  are 
available,  and  for  the  extended  format 
33  digits  are  available.  Tha  Alsys  ADA 
compiler  maps  ADA  floating-point  types 
onto  the  IBM  formats  in  the  following 
manner:  the  predefined  floating-point 
types  SK0RT_FL0AT,  FLOAT,  and 
LONG_FL0AT,”"are  represented  in  the  IBM 
short,  long,  and  extended  formats 
respectively,  however,  for  decimal 
accuracy  these  three  types  are  limited 
to  6,  14,  and  IS  decimal  digits 
respectively.  It  is  assumed  that  this 
was  done  to  prevent  loss  of  accuracy  due 
to  rounding  error.  As  for  the 
user-defined  floating-point  types  in 
ADA,  they  are  represented  in  the 
appropriate  IBM  format.  For  instance: 

type  MY_REAL  is  digits  15; 

type  Y0UR_REAL  is  digits  12; 

In  this  example,  MY_REAL  would  be 
represented  in  the  IBM  extended  format 
and  YOUR_REAL  in  the  long  format.  Even 
though  a~number  with  15  decimal  digits 
could  be  represented  in  the  IBM  long 
format,  the  results  of  computations  on 
this  number  could  contain  errors  in  the 
least  significant  digits.  By 
representing  the  number  in  the  extended 
format,  errors  occurring  in  the  least 
significant  digits  will  not  degrade  the 
accuracy  of  tha  defined  type.  It  should 
be  made  clear  that  the  predefined  types 
SH0RT_FLOAT,  and  L0NGJFL0AT  are  not 
required  by  the  language  definition  but 
are  provided  by  the  Alsys  environment  in 
keeping  with  recommendations  in  the 
language  reference  manual. 

The  algorithms  in  the  Cody-Waite 
manual  recommend  subtle  variances  to  bo 
used  on  machines  using  different  floating¬ 
point  representations,  (i.e.  binary,  octal, 
hexadecimal)  While  these  variances  do 
cause  minor  differences  in  .accuracy,  by 
using  the  algorithms  for  binary  machines 
and  extracting  a  base  two  representation 
of  the  floating-point  numbers,  the 
package  used  in  my  project  provides 
portability  and  results  that  are 
accurate  within  the  defined  type. 
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Nov  that  vo  have  some  of  tho 
preliminaries  out  of  tho  way,  lot'*  take 
a  look  at  a  representative  example  of 
tho  function*  available  in  tho  oath 
package.  For  the  purposes  of  this 
discussion  tho  natural  logarithm 
function  will  be  used  as  an  example  of 
tho  other  functions  in  the  package. 

Since  the  focus  of  chis  paper  is 
not  numerical  methods  the  algorithm 
vill  be  discussed  in  very  general 
form  and  a  copy  of  the  code 
will  be  provided  for  those  who  wish 
a  more  detailed  consideration. 

In  order  to  calculate 
the  logarithm,  three  steps  must  be 
taken: 

1.  Reduce  the  argument  to  a  small 
logarithmically  symmetrical  interval 
around  1. 

2.  Compute  the  logarithm  for  the 
reduced  argument  using  a  polynomial 
approximation (Cody-Waite  use  a  minimax 
rational  approximation  generated 
especially  for  their  work) . 

3.  Reconstruct  tho  desired  logarithm 
from  it's  components. 

Attempts  to  calculate  the  logarithm 
for  invalid  arguments  ore  handled  in 
various  ways.  An  attempt  to  calculate 
the  logarithm  for  a  negative  value 
causes  the  function  to  send  an  error 
message  to  the  standard  output  and 
calculate  tho  logarithm  of  the  absolute 
value  of  the  argument,  similarly,  an 
attempt  to  calculate  the  logarithm  of 
zero  causes  the  function  to  send  an 
error  message  to  the  standard  output  and 
return  tho  largest  negative  number 
representable  by  the  machine.  Any  other 
exception  raised  In  tho  logarithm 
function  causes  an  error  message  to  bo 
sent  to  the  standard  output  and  a  value 
of  zero  to  be  returned.  The  above 
technique,  employed  wherever  possible 
throughout  the  packago,  prevents  a 
complete  crash  of  the  program  while 
notifying  the  programmer  that  an  error 
has  occurred. 

TESTING 

After  reconstructing  the  missing 
lines  of  codo  from  tho  package  it  was 
compiled  in  its  generic  form.  However, 
any  attempt  to  compilo  a  program  that 
instantiated  the  package  caused  the 
compiler  to  crash.  Tho  problem  turned 
out  to  be  a  documented  bug  in  that 
version  of  the  compiler.  While  waiting 
for  a  new  version  of  the  compiler  to  bo 
delivered,  the  packago  was  compiled  and 
tested  as  a  non-generic  for  all 
floating-point  types.  Two  typos  of 
testing  for  accuracy  were  performed. 
First,  the  Cody-Waite  tost  routines 


provided  with  the  package  were  used. 

The  test  routines  use  2000  random 
arguments  along  with  various  arguments 
used  to  excercise  the  exception 
handlers.  The  tests  for  accuracy  are 
performed  using  various  mathematical 
identities. 

Returning  to  the  natural 
logaritnm  function,  for  example,  one 
accuracy  test  performed  measures  the 
maximum  relative  error  in  the  identity: 

la(x)  =  ln(l7x/l«)  -  In (17/ic) 

so  we  measure  the  error  E  as 

E=(ln(x)-[lm(l?x/ic)-ln(17/l<)])/ln(x) 

After  running  these  test  routines 
it  was  found  that  at  no  point  did  the 
maximum  relative  error  exceed  the 
digits  of  accuracy  specified  in  the 
floating-point  type  definition. 

The  second  type  of  accuracy  testing 
involved  comparing  the  results  to 
accepted  values.  Although  not  yet 
complete,  the  comparisons  performed  so 
far  show  that  this  package  provides 
exactly  the  same  results  as  the  IBM 
VS/FORTRAN  version  3.0  routines 
currently  in  use  at  the  University  of 
Mississippi.  A  comparison  of  the 
results  obtained  from  the  package  for 
several  different  floating-point  types 
against  tables  of  values  produced  in 
1941  for  the  city  of  New  York  under  tho 
sponsorship  of  the  National  Bureau  of 
Standards  indicates  that  the  values  are 
completely  accurata. 


Testing  the  efficiency  of  the 
functions  has  not,  as  of  this  writing, 
been  initiated. 

SUGGESTIONS  FOR  IMPROVEMENT 

As  stated  in  the  abstract,  one  of 
the  goals  of  this  project  was  to 
encourage  students  to  pursue  future 
pro.*  jets  in  ADA  by  providing  them  with 
significant  material  to  start  with. 
Using  the  natural  logarithm  once  again 
as  a  representative  examplo,  some 
suggestions  for  improvement  of  the 
packege  should  be  discussed. 

The  logarithm  function  uses  two 
separate  approximations,  one  for 
floating-point  types  of  loss  than  ton 
digits  of  accuracy  and  one  for  those 
with  more.  This  clearly  does  not  make 
full  use  of  ADA  generics.  Modification 
of  the  functions  to  provide  soparate 
approximations  for  a  uidor  range  of 
floating-point  typos  would  not  be 
difficult.  Modification  of  the 
functions  to  provide  more  than  eighteen 
decimal  digits  of  accuracy,  (whenever  a 
compiler  capable  of  this  becomes 
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available  to  the  University} ,  would  bo 
another  significant  improvement.  Since 
all  of  the  functions  in  the  package  are 
separately  compiled,  modification  of  the 
package  could  be  performed  by 
individuals  or  teams  easily  and 
efficiently. 

COKCLUOIOW 

This  package,  as  it  stands, 
provides  a  reliable  and  accurate  base  of 
mathematical  functions.  Zt  Is  hoped 
that  the  availability  of  this  package 
will  encourage  engineers  and  other 
scientists  at  the  University  of 
Mississippi  to  take  advantage  of  some  of 
the  features  of  the  ADA  programming 
language.  The  package  has  been  ported 
to  the  I DM  PC/AT  and,  as  other  compilers 
become  available,  will  be  ported  to  the 
various  machines  at  the  University, 
including  the  Cyber  supercomputer. 
Finally,  zt  is  my  strong  desire  that 
students  will  find  this  fertile  ground 
for  challenging  and  significant 
projects. 
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Abstract 

Ortuwf-vuiieu  Kh*»w*  W?  t?l»«ei«»t.  sad  *s*4< 

•Jar  i»s  -((*eUr<4  has?  bee*  C<«liv«l/  *»«d  I* 

lW  ^lUi  4r~<»  a*4  l*«f4*»*«*l»Ue*  fiiMi  tl  k<I*»M  it?* 
wfopmeat,  |»  i VI*  p-p-f,  ike  t»*»  ef  H**'*1"  <tev»<*|“?-iU*« 
IxMktViM  for  uiljitH  iV*  stalk  »*4  4j»»kK  pr*petiirs  of 
Urge  rtHttiw  h  Th«*e  *u  ****** 

i»  pC*g»M»  C»*Spl«h*»s»Wl  Inlln,  aad  Vetii<»tt»« 

w*  »w  mnvwuuiy  c**im  ru-  ci-pM 

W?*4  taler  mediate  t*fti~t»ui««i  for  Ada  h '*'**•“.  *1  V*tb 
tatra-nwsUW  and  tswr-m-dsW  knk  An  *p>r»i**«U»pre’*vh 
h<  4-viiWsg  iV?  suitably  and  smp»*g  tub*  ►(  Ada.  with  t« 

*I»<|  u  iV?  tniKi:;  I #*»  xiaph  K(?**<»uim  *f  Ada  ft* 
ttaau.  V*  4-«  pie~«ltd  We  describe  h*w  Ult «»»  V*  miS»?4 
14  elicit  tafociaaiWMi  a  foist  the  rial*  scmaaiks  *1 V  pmetain 
|i*p*»4«*e*  t*J*iV*fc*.  f*c  fo*h  stalk  a*d  djaanuc  asalju-s. 

Me  ««4  14  dekae  pteervn  “hkh  way  be  swabei 

thaa  iV?  ^iui  itself.  TV**?  prejnttwsa  u«  We  gcactaieJ 
it  u  wteout  IwVlM  aad  eiertlk  'W  dynamic 

semantic*  of  the  ocigisal  prelaw  TV?  b«W»**»  of  iV**<  de- 
rompwUioa  »<V*m*«  hi  pr**ram  a*4  <tiil<ai»*  l* 

kiMiliKwef, 

1  Introduction 

Kvcdutioo  U  on  intrinsic  behavior  of  oil  natural  on<]  artificial  sys¬ 
tems  Softwvc  systems  also  evolve  in  Of  dcr  to  moinUin  compatibility 
with  lb?  domain  in  whkh  th-y  o re tntWieJ  Automated  * upp<x t  for 
mflwve  evolution  «  mandatory  hi  Ivge  *y*tem*  in  order  W  provide 
coal  effective  computcuiaiion  in  lb?  domain  of  application  Foe  lb? 
dong  n  on  J  implementation  phase*  of  software  development,  technique* 
tike  slepwm;  refinement,  modular  decomposition  and  itiuctuted  pro¬ 
gramming  or?  being  successfully  use.d  Tb?  tciesreb  in  tb?  wiou* 
vpseu  of  software  engineering  ho?  been  effectively  tiulited  In  pf«» 
lyjnns  pro*r imu(  enviromncnu  Ibol  or?  rspidly  beiaj  mitodutcd 
Ut  *ofl*»re  production 

Ttx*«  novel  protramminj  jiaradijtin,  ucbni<ju<u  and  loobt  may 
lead  to  njalfican*.  productivity  (ain*  for  dcvctopiag  new  *y>t?trv>  Tbcif 
rot?  in  maintaining  cxkting  toft  war?  that  it  evolving,  or  antiwar?  being 
developed  in  tbe  traditional  way,  ic  tatber  limited.  Tlie  cent  of  tod- 
ware  maintenance  now  amount*  to  more  than  M%  (II)  of  tbe  overall 
tofkware  ecu  la  of  about  100  billion  dollar*  per  year  (tj  In  tbe  aUence 
of  a  complete  and  eoniiatent  documentation  of  tbe  ie<)uireitwnu  and 
deatgnr  tpceiflta'.ion  of  tbe  aoftware  tyatem,  often  tbe  source  code  i* 
tbe  only  genuine  repreaentatkm  of  tbe  ayttem  and  it  baa  to  analyied 
and  underatood  for  any  maintenance  activity  (J) 

We  are  itudymg  the  nature  and  effectives?**  of  program  deeom* 
poti lion  technique*  m  tbe  context  of  toftware  evolution  (or  loflware 
maintenance).  Tlii*  rocerdi  u  u*ed  toward*  the  development  of  a  pro* 
gram  analyier  that  can  automate  tbe  technique*  for  dccompotmg  large 
multi-module  program*  and  umplify  their  italic  and  dynamic  analy¬ 
te*.  Although  tbe  analyzer  provide*  a  new  penpeetive  to  the  program 
comptebeniion  and  debugging  proec**e*,  we  envuion  It*  application 
m  a  wider  domain  of  automated  tuppoti  for  program  development, 
letting,  and  verification  effort*. 


The  p»pet  c*n  be  broadly  divided  into  l»o  part*  In  ieetion  3. 
“e  b?gm  with  a  d»cu«*ie4*  on  tbe  vWhtbty  and  eeeping  rule*  of  pto 
grattumng  language*  Tbi*  kW  the  *tage  for  presenting  Out  approach 
Toward*  managing  and  dwplaymg  *iaiie  mfeemation  about  pregrama. 
In  iection  3,  w?  provide  the  VVibdity  Tfow  Crapb  ( W6)  n»il*l  a* 
an  intermediate  teprerentation  for  large  multbmodok  program*.  Th« 
model  can  be  u*ed  to  elicit  information  about  tbe  italic  proper  tie*  of 
program*  Tbi*  i*  coveted  in  KCtiOn  d. 

In  aection  5,  w?  comider  tbe  Control  Flow  Cr»pb*  (CF<7)  that 
provide  the  haul*  for  the  decompmUten  Hberne*  for  dynamic  proper- 
tie*.  In  tbe  next  *ection.  we  introduce  program  projection*  in  both 
italic  and  dynamic  context*.  We  u»c  dependence  relation*  among  the 
itatemenu  and  the  variable*  of  a  program  for  defining  and  generating 
these  projection*.  Static  projection*  are  useful  for  program  verifica¬ 
tion  and  their  dynamic  counterpart*  are  suited  foe  program  texting 
and  debugging  with  actual  input  value*  for  the  variable* 

We  present  rumoneied  VfCt  and  CFGt  for  Ada  program*  in  sec¬ 
tion  7  Tbi*  h  followed  by  seme  of  tbe  **fieni  feature*  of  a  prototype 
program  analyzer  for  Ada  program*,  In  section  9.  w?  briefly  discus* 
the  pocenlial  of  Our  approach  for  *uppociing  software  evolution.  Fi¬ 
nally,  we  addles*  tbe  current  statu*  of  tbi*  project  and  provide  some 
direction*  for  future  work. 

2  Visibility  Control  in  Programming 
Languages 

In  prog-nmmmg  languages,  the  visibility  issue*  ate  described  m 
term*  of  derivation  of  entitle*  and  the  related  *<ope  (tbe  portion  of 
the  program  text  where  n  derivation  i*  potentially  visible)  of  these 
derivation*.  In  a  derivation,  a  softwve  entity  i*  associated  with  a 
name.  Mo*l  language*  allow  tbe  mage  of  tbe  same  name  In  multiple 
derivation*  and  the  scope*  of  wiou*  derivation*  can  overlap.  Some 
language*  provide  overloading  of  nvtx*  a*  well.  Thu*,  any  descrip¬ 
tion  of  visibility  control  ibould  include  the  dcclvaiion  and  nvning 
mechanism*  with  visibility  and  overloading  rule*. 

A  program  may  use  many  of  Ihe  visibility  construct*  provided  by 
the  language.  For  our  discussion,  w?  shall  consider  the  Ada  program, 
ming  language.  Tbe  concept  of  a  declarative  context  l*  important  in 
this  approach.  A  program  i«  translated  into  a  graph,  each  node  of 
which  correspond*  to  a  derivative  context,  interconnected  with  arc* 
representing  the  visibility  flow.  The  notion  of  derivative  eonlexi  can 
be  traced  back  to  cvly  language*  like  FOKrilAN,  that  tuppoti  the 
declaration  of  subprogrvn*  with  locally  declved  vviable*  which  vc 
not  visible  outside  the  luhprogrvrt  In  ALGOL  CO,  a  derivative  con¬ 
text  k  formally  defined,  along  with  other  aspect*  of  the  language. 
Some  obviou*  exvnplc*  of  declarative  context*  are  /aacfiaa  and  struct 
in  C.and  yreerfart./aaefis*  and  rrconf  in  I’aaea).  Among  more  recent 
language*,  Ada  includt*  ftcltfc  vid  Modula  has  mod  s/e  a*  new  type* 
of  declarative  context*.  Object-oriented  languages  like  SmallTalk  have 
eftrr  and  ol;rcf  primitive*  that  correspond  to  derivative  contexts. 
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A  declarative  context  provide*  S  ftittwwprk  fef  -he  tiling  new  »n- 
lilse*  and  doing  fCHnpUlalten  (fer  proceduta)  en<tlte»l  V  »g  ibnse  rn> 
title*.  The  dsrlaration  of  an  mill;  may  requite  a  user  defined  type 
that  may  of  way  not  have  been  locally  declared  Similarly.  an  entity 
v»*4  in  the  compulation  part  fan  »t*0  be  non- local  Pm  this  reason, 
programming  language  provide  visibility  Raw  mechanism*  to  import 
non-toeal  entities  from  ocher  declarative  rnatexu.  These  meehanum* 
ran  be  implicitly  present,  m  ta  the  caw  of  procedure  noting,  e«  aa 
explicit  language  coruttucl  can  be  Used  tile  the  nil  clause  to  import 
the  public  entitle*  of  aa  Ada  ystltye 

2.1  Implicit  Netting 

la  A  li  t  01.  M,  dot  IT'S  U  the  primary  Vntpility  mechanism  fat  fa. 
cilitating  the  use  of  non-local  entitm*  miom  the  declarative  context 
boundaries  The  notion  of  netting  an-)  the  associated  Row  of  visibility 
Item  the  parent  context  to  a  r hild  context  (and  not  vice  vers a)  u  in¬ 
herited  by  KVerat  other  block  structured  language*  tar  lading  Pascal. 
Modul*(>3)  and  Ada. 

2.2  Linear  Elaboration 

In  W»ay  language*  ble  Pascal,  Ada  and  t*.  linear  elabccation  t>  another 
visibility  mechanism  that  implicitly  control*  the  visibility  of  entitle* 
within  a  declarative  context  With  linear  elaboration,  tl  W  ittegrj  to 
two  an  entity  that  ha*  not  been  declared,  at  least  partially,  before  tbe 
entity  U  actually  u»eet.  Modula  doe*  not  depend  cm  linear  elaboration 
and  tbe  visibility  w  uniform  acts**  the  entire  declarative  context 

2.3  Explicit  Nesting 

Traditionally,  heating  M  implied  when  a  child  declarative  context  i* 
declared  within  the  parent  dcelaraiive  context  In  Ada,  netting  can 
be  explicitly  specified  with  tbe  it  itftntlc  and  *rp4r*lc  clause*.  They 
tuppotl  aeparate  compilation  of  package*  and  procedure*,  while  main, 
taimng  visit, lily  due  to  implicit  netting 

2.4  Structured  Types 

An  entity  declared  to  lie  of  structured  type  gel*  all  tbe  field*  (or  the 
lubcomponenU)  of  the  aatociated  type  Thu*  stntt  type  of  C  and 
record  type  of  I’atca]  and  Ada,  both  have  inherent  *  outre  of  vitlbility 
that  ran  he  iui|ioited  by  other  entitle*.  In  eontltucu  like  modifc  of 
Modula.},  it  i*  pouibte  to  associate  proeedural  code  at  a  aubcompo- 
nent  of  a  ilrurtuted  entity.  These  language  primitive*  ran  be  used  for 
direel  implementation  of  *ltlr*c<  d«l *  type*.  Further,  language*  like 
SmallTalk  extend  thi*  aUtract  data  type  Implementation  mechanism 
with  tins  conitruet*.  Here  it  ia  possible  to  inherit  lubcomponenU 
from  other  context*  mmg  eljctl  mltnt*n«  rule*  that  include  transi- 
tlvity  These  object-oriented  language*  can  supi-ul  *«  entire  hierarchy 
of  context*  related  lk  gli  visibility  flow  relation*  [C] 

2.5  Previous  Work 

Traditionally,  viubility  control  mechanism*  have  been  de*cubed  infor¬ 
mally  It  u  a  eonunon  practice  to  provide  UN’F  (context  free)  daerip- 
lion*  for  representing  the  lyntactical  features  of  programming  lan¬ 
guage*  (1]  Formal  methods  do  exist,  however,  for  representing  the 
non  syntactical  aspect*  (that  include*  visibility  control}  of  program- 
ming  languages  [10J.  In  [13]  the  disadvantages  of  this  formal  approach 
for  describing  the  visibility  rules  are  mentioned  and  a  visibility  graph 


model  ha*  been  ptopwed  Visibility  mechanism*  arc  described  us¬ 
ing  the  concept*  of  rrf  sinhss  of  acre**  and  yr*n*i*»  of  access.  Tbl* 
model  i*  aimed  at  language  designer*  for  justifying  new  mechanisms 
and  programmer*  foe  identifying  t  he  »uli*bility  of  a  methanUm  within 
a  program.  H  aim  provide*  a  graphical  repte*entaiioci  of  visibility 
ptopetth*  of  a  program. 

3  Visibility  Flow  Graphs 

The  Visibility  Flow  UtapK*  consist  of  sltuctvtcd  nodea  and  edge*  in¬ 
terconnecting  the  node*.  A  node  corresponds  to  a  declarative  context 
(DC)  while  tbe  edge*  Interlinking  DCs  depict  visibility  flow  informa¬ 
tion  Within  a  declarative  context,  a  seqventlal  list  provide*  the  skele¬ 
tal  structure  connecting  variou*  unit*,  of  lype*  declarative  or  tcquWi- 
tionary  A  unit  may  corrt*|>ond  to  an  domic  program  construct  like 
a  variable  declaration  (declarative}  or  a  statement  (reqmsitionsry) 
A  nen-atomic  unit  I*  aatociated  with  another  declarative  context  that 
may  participate  in  the  visibility  flow  information  of  the  current  declar¬ 
ative  context.  We  define  the  visibility,  declaration,  requirement  and 
provision  Set*  lor  the  entitle*  within  the  framework  of  V? Cs. 

The  IT C*  ditplay  the  interconnection  of  the  declarative  context* 
in  a  program.  Depending  on  the  programming  language  and  the  a*, 
seriated  visibility  construct*  used,  a  declarative  context  may  corre¬ 
spond  to  an  entire  program,  a  module,  or- a  part  of  the  module  This 
representation  i*  uniform  aerew*  the  inter  and  inlra-uualuk  visibility 
representation.  This  uniformity  it  in  sharp  contrast  with  the  duality 
of  ’large'  and  'sinali'  program*,  associated  with  the  Module  Inter¬ 
connection  iuuiguage  (MIL)  approach  (0)  toward*  large  program*. 

Atomic  unit*  never  exist  on  their  own  and  are  alway*  contained 
within  n  DC  An  entity  may  have  several  attribute*  hut  usually  lu 
name  la  suflicienl  for  thi*  discussion  of  the  ITC  model. 

3.1  Declarative  Contexts  and  Units 

The  declarative  context*  constitute  the  node*  of  the  vuihility  graph*. 
A  context  i*  structured  as  a  sequential  list*  of  unit*  corresponding  to 
declaration*  and  statements.  A  declarative  unit  may  declare  a  new 
entity  (e.g.,  n  variable)  and  may  require  Other  entitles  (the  type),  A 
unit  corresponding  to  a  statement  may  require  accea*  to  other  entities 
(like  variables,  procedure*  etc.)  Thus,  there  are  two  attribute*  of  each 
unit'  'llte  tel  Dt  include*  the  entitle*  declared  in  unit  i.  Similarly,  ft( 
correspond*  to  the  set  of  entitle*  that  arc  required  by  unit  f. 

To  accommodate  linear  elaboration,  cacti  unit  it  assigned  an  index 
number,  denoting  it*  position  in  the  sequential  unit-list  associated 
with  a  declarative  context.  Thi*  ordering  can  readily  he  determined 
for  the  declarative  part  of  a  context  aa  any  non-atomie  declaration  1* 
treated  a*  a  different  declarative  context.  Far  the  procedural  part,  it  1* 
necessary  to  provide  an  ordering  function  to  accommodate  compound 
statement*  like  conditional*  and  loop*  (0] 

3.2  Visibility  Function  for  n  Context 

Using  the  definitions  of  units  and  the  ordering  function,  the  visibility 
function  V  can  he  defined  at  the  end  of  unit  i  of  a  declarative  context. 

_ Vi  =  0’,_iUV  Y-DAUD,  (I) 

1 AU  |4otr*mtnIn£  Un(\u£c*  employ  thU  tcqivrallil  JuitifKwlion  of  Jttlw*- 
tkwtf  aim!  lUlcfiMiU.  Although  for  »ut«imiu,  lUi  MqutAii*!  nilurt  provide* 
the  control  flow,  IU  imjxxt  a/xt  for  nubility  putj»o»e«  it  relevant  on)/  when  lintAr 
cUbor  Alton  u  effrctive  Thu*.  foe  ModuU>*  tlnUunont  the  Kqirntld  mjm<1  of 
t)u«  lit!  it  lorulntlnt. 
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Http.  U-i  corresponds  to  the  visibility  value  afirr  unit  1-1,  and 
D,  corresponds  to  the  entitle*  provided  t>y  the  fth  unit-  The  term 
>i'  denote*  the  visibility  imported  from  other  contexts  and  should  be 
known  before  1)  can  be  effectively  determined  Subtracting  Or  take* 
care  of  visibility  hiding  due  to  a  redeclaration  of  art  entity  ai  ttnil  I 
that  was  already  visible  from  some  ttoudoeal  rent  ext  For  language* 
not  using  linear  elaboration.  1*,  ■  1',  Joe  all  iV. 

Thus  >"(  correspond*  to  both,  the  visibility  before  unit  t  +  I  and 
Just  after  the  fth  unit,  1*  corresponds  to  visibility  before  tbe  first  unit 
and  include*  only  I','  that  is  imported  from  other  declarative eoni'XU. 

3.3  Importing  tout  Exporting  Visibility 

In  tbe  definition  of  tbe  visibility  function  V  within  a  declarative  con¬ 
text,  the  term  l"  corresponds  to  the  visibility  imported  from  other 
context*.  To  accommodate  linear  elaboration,  l"t*  i*  defined  for  each 
unit.  In  a  CFG,  an  are  (Af.A?)  correspond*  to  the  flew  of  visibility 
from  the  declarative  context  Af  (the  source)  to  the  context  ,Y  (the 
destination).  The  context  .V  i*  said  to  import  visibility  of  entities  re¬ 
ported  by  the  context  Af.  With  linear  elalmratlon  the  interpretation 
of  visibility  import  is  dependent  on  the  actual  position  of  the  flow  arc 
within  the  destination  context  Tlius.  the  target  of  the  are  (Af.iV)  is 
qualified  with  index  i.  'Die  following  equation  describes  the  Imported 
visibility  for  a  declarative  context  ,V: 

»?-  U  w.t-xt  ovrtK,'St  (3) 

I ^  )C  Vf* u\d|S| 

Here.  IK  l«  a  function  defined  at  the  target*  of  tbe  I  Wedge*.  Slim 
daily,  OCT.  defined  at  the  source  nodes,  describes  the  export  of  enti¬ 
tles  from  the  declarative  context  Af  to  ,V  The  source  Af  is  qualified 
with  index  j.  With  the  definitions  of  the  functions  IS  am!  OCT.  that 
are  language  dependent,  it  Is  possible  to  translate  the  idiosyncratic* 
of  various  language-specific  rule*  that  govern  visibility  flow  across  the 
declarative  wilext*. 

3.4  Requirement  mid  Provision  Sets 

’Ihe  set  ll(  contains  all  the  entitle*  that  are  required  in  unit  i  'Hie 
union  of  these  set*  over  all  unit*  m  a  context  leads  to  the  requirement 
set  corresponding  to  that  context,  it  U  defined  as:  Us  c  u£,ff, 
Similarly,  /J.v  a  V?myl)(,  that  describes  tbe  set  of  all  local  declarations 
If  the  requirement*  of  a  context  can  be  met  locally  then  Its  £  O.v 
and  for  linear  elaboration: 

tor  a  well  formed  program,  it  U  essential  that  all  the  required 
entities,  within  a  declarative  context,  should  be  provided  locally  or 
imported.  This  is  equivalent  to  saying  that  the  relation  ID  £  l’,  be 
true  for  all  i. 

The  provision  set.  corresponding  to  an  entity  e,  Is  defined  as  fob 
lows 


/>(0  =  {/(« e  «/}  I 

The  entities  c  and  /  could  be  declared  in  the  lame  or  dilferenl 
declarative  contorts.  Tbe  information  contained  hi  provision  sets  is  a 
generalisation  of  the  traditional  cross-referencing  outputs. 


4  Generating  Secondary  Information 
from  VFGs 

A  VFG  stores  tbe  raw  information  about  the  corresponding  pro¬ 
gram  It  can  be  used  to  generate  secondary  information,  for  answering 
on-demand  queries.  In  this  section,  we  describe  this  generation  pro¬ 
cess.  This  <an  provide  the  <e«e  foe  implementing  the  primitive*  of  a 
program  fstry  Unf*»fe  (<5)  to  elicit  information  about  static  semantics 
of  programs. 

4.1  Local  Visibility  in  a  Declarative  Context 

All  tbe  local  declarations,  subject  to  linear  elaboration,  provide  local 
visibility  for  a  declarative  tontexl  Tbe  generation  of  local  visibility 
requires  a  single  pass  over  tbe  unit-list  of  the  declarative  context.  This 
can  tcadily  tie  determined  using  equation  I  Iteratively  for  each  f. 

4.2  Global  VUibility  in  a  Declarative  Context 

Olobai  visibility  in  a  declarative  context  tan  he  determined  wing  cqua. 
lion  I,  before  the  visibility  function  can  he  generated  for  a  specific 
IIC,  it  should  Ire  known  for  all  the  declarative  contexts  that  export 
visibility  to  the  DC  under  consideration  The  CFG  edge*  (describ¬ 
ing  visibility  flow)  impose  a  partial  order  on  the  CFG  nodes  and  it 
is  possible  to  predetermine  all  such  DCk  from  which  the  current  DC 
is  lm|iottiitg  visibility.  This  scheme  ensure*  that  only  the  directly  af¬ 
fected  part  of  the  CFG  of  a  program  ha*  to  he  regenerated  when  the 
program  is  incrementally  modified. 

4.3  Requirements  in  a  Declarative  Context 

The  determination  of  the  requirement*  of  a  declarative  context  is  the 
union  of  requirement  *eu  of  all  the  unit*.  For  a  well  formed  pro¬ 
gram.  the  requirement*  should  he  provided  l>y  the  visible  entities, 
as  described  by  the  global  visibility  function.  If  the  program  is  not 
complete,  then  it  is  meaningful  to  define  an  IMPORT  set,  for  the 
program  The  aggregation  of  all  unresolved  requirements  in  a  pro¬ 
gram  constitute*  the  IMPORT  set.  It  can  be  generated  by  collect¬ 
ing  all  It4  -  V*.  where  It 4  i*  the  requirement  set  of  DC  d.  Thus, 
IMPORT  «  Us.jl/v4  -  W).  Here  is  the  set  subtraction  opera¬ 
tor.  '11ns  import  Kl  for  a  module  « the  RKQVIRDMKST  set  defined 
and  used  In  the  MU,  approach  [0], 

4.4  Provision  Sets 

The  provision  set  for  an  entity  can  he  determined  using  equation  3 
Fur  tin*,  each  requirement  of  all  declarative  context*  that  can  import 
visibility  from  the  current  DC,  must  lie  considered  for  resolution  with 
the  local  or  imported  visibility.  The  aggregation  of  provision  set*  of 
all  declarative  contexts  constituting  a  module  is  a  more  generalized 
form  of  the  PROVISION  set  defined  and  uied  in  the  Mil,  context  [S], 
and  the  traditional  cross-referencing  of  programs.  A  provision  set  con¬ 
tains  the  entitles  that  are  being  provided  to  other  contexts  (or  parts 
of  a  programs).  It  includes  the  actual  entities  that  have  unresolved 
requirements,  and  the  declarative  contexts  containing  them.  It  should 
he  distinguished  from  the  set  of  entities  that  are  visible  in  other  con¬ 
texts  (or  modules).  Thai  information  directly  corresponds  to  visibility 
or  potential  provision  of  entities  for  resolving  some  requirement. 
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$  Control  Flow  Representation  of 
Programs 

Control  graph*  have  been  used  In  vartcu*  context*  related  la 
compilation  and  optimiraiiert  cf  program*  (3)  “Jit?  font  tel  flaw  prop¬ 
erties  may  not  be  explicitly  present  in  lit?  syntax  tree  corresponding 
in  *  program.  During  the  compilation  of  a  program.  the  syntax  tic? 
w  only  an  intermediate  representation  for  lit?  program  syntax  tit? 
tyntax  Ur?  t*  augmented  with  lb?  centre!  flaw  information  Ibai  is 
explicitly  *iorcd. 

tb?  CFG  i*  defined  recursively  At  lb?  highest  level,  it  t*  a  >?■ 
quenttal  list  of  statement*  of  tyjx*  simple  and  compound  A  node 
fottl4  be  atomic  if  ii  correspond*  10  a  simple  Matcrocnt  ItV?  assign- 
m?nl  Par  compound  statement*  lib?  conditional*,  it  corresponds  la  a 
ton t to)  flaw  subgraph  lltal  include?  ih?  cuadih**.  lb?  (ben  {tan  and 
lb?  d>(  pari. 

Tit?  CFG  i*  a  lie?  far  proclaim  witboul  any  arbitrary  fata  state- 
menu.  Bach  subunit  of  tuch  a  program  ha?  a  single  ?nlty  and  exit 
poinu.  Ka<b  assignment.  procedure  call  and  null  statement  U  a  limpl? 
nod?,  and  loop*  and  conditional*  cot  impend  to  a  subtree. 

Tb?  CFG  of  a  program  provide?  lb?  framework  far  program  anal. 
>-*i*  and  ha*  attribute*  far  defining  and  determining  additional  prop* 
ertie*  pertaining  to  Malic  and  dynantic  analyte*  of  the  program.  A* 
dt*cuM?d  in  tb?  next  section,  lb?  attribute*  Include  tb?  dependence 
relation*  IV.  S\>  and  Pg  that  are  need  far  generating  *tatic  and  dy< 
nattuc  projection*.  In  addition,  there  at?  attribute*  far  monitoring  tb? 
program  trajectory  while  il  U  executing.  The*?  in  conjunction  with 
lb?  dependence  relation*  nr?  u*?d  in  generating  more  precise  program 
ptojeelion*. 

6  Program  Projections 

In  ibi*  *ection,  w?  define  program  projection*  of  two  type*;  italic  and 
dynattuc.  Dependence  relation*  are  u*?d  far  ibi*  purpose  We  define 
litre?  *ucb  relation*  and  describe  bow  they  can  be  determined  for  a 
program  in  both  itatic  and  dynamic  context*  These  tclatiom  can  al*« 
be  uted  in  yroo/m«i*tc**nc<  and  (estiny  m*iaftit*nee. 

We  define  program  projection*  to  be  a  »ub*et  of  al!  program  Mat?, 
menu,  maintaining  the  original  order  and  a  part  of  the  overall  *eman- 
lie*.  A  projection  P£  of  program  /’  U  defined  for  a  variable  if,  t>  G  V*. 
and  from  lUtcmcnt  Sj  to  Sj.  The  aim  is  to  conMruct  Pr  with  only 
tbo«e  statement*  from  the  sequence  5r  to  5i  *uch  that  tit?  value  of  v 
is  tame  after  executing  /’/•  a*  it  would  be  after  statement  Sj  when  /* 
i*  executed. 

Static  analyst*  ha*  been  uted  earlier  to  generate  useful  informa¬ 
tion  about  programs  for  compilation,  optimisation,  testing,  and  un- 
demanding  purpose*  [5]  Projections  can  be  defined  based  only  on  the 
static  analysts  of  the  program,  similar  to  program  slicing  (12)  or  partial 
statements  (3).  Such  projections,  however,  have  limited  applicability 
while  executing  a  program  with  actual  values  for  testing  and  debug¬ 
ging  purposes.  In  this  section,  we  define  the  dependence  relations  that 
can  be  used  in  tb?  context  of  both  static  and  dynamic  projections  of 
program*.  Ptojeelion*  defined  in  dynamic  contexts  are  more  precise 
compared  to  their  static  counterparts. 

0.1  Dependence  Relations 

We  define  three  relations  that  are  useful  in  capturing  the  static  and 
dynamic  properties  of  a  program. 


•  $V  '  (*,«•)  0  if  statement  *  depend*  on  (me*)  lb?  input 
value  of  variable  c. 

•  Ijt  :  (*,#)  6  IV.  if  the  output  value  of  variable  «  depend*  on 
execution  cf  lb?  statement  * 

•  t«*  f  (v.w)  G  tV.  if  the  output  value  of  v  depend*  on  the  input 
value  of  u. 

While  considering  the  dependence  relation*  of  multiple  program* 
(or  multiple  part*  of  the  tame  program),  a  superscript  w  u»ed  to  asso¬ 
ciate  a  program  with  lu  relation*.  Thus,  Vf  denote*  the  )jt  rrlatien 
of  ptogram  /*. 

Program  projection*  ea«  be  generated  u»tng  the  second  dependence 
relation,  lj.  1'or  a  program  P  and  variable  v: 

^M(*I(v.s)GP/)  H) 

Per  these  relations,  the  input  and  output  values  correspond  to  the 
slate  before  and  after  executing  the  program  (oc  it*  part*).  ‘Pbese  do 
pendente  relation*  can  easily  be  defined  for  simple  statements.  Other 
slatments  can  be  visualised  a*  a  Sequence  of  *maller  statement*.  ’Die 
following  definition*  for  the  modification  and  preservation  of  variable 
tt  in  a  program  P  will  be  Used  later  for  generating  these  relation** 
MOD  «  {iju  U  modified  by  the  program  P) 

PKK  ■  {v|v  is  preserveil  (not  modified)  in  /’) 

Itelalion  IV  foe  a  program  P  can  be  defined  in  term*  of  .S\>  and 
IV  a*  follow*.  Por  variable*  o  and  u,  (i-.u)  G  IV  If  any  of  the  two 
following  condition*  it  satisfied; 

I.  The  variable  u  depend*  on  s  ( or.  (t-,s)  G  ijr)  and  the  statement 
*  In  turn  depend*  on  variable  u.  t.c ,  (»,u)  tj  i\- 

3.  The  variable  v  I*  preserved  by  the  program  P. 

Till*  lead*  to; 

IV  =  Vt  •  Sv  U  /V  where /V  a  {lv.  v)|o  G  PUB)  (5) 

Here,  r  G  V,  the  set  of  all  variable*  in  program  P  and  the  compo- 
sitlon  operator  “  *  ha*  a  higher  precedence  than  U  and  n, 

G.I.l  Null  statement 

A  program  P  (bat  consists  of  a  single  null  statement  doe*  not  modify 
any  variable.  Por  all  v  G  V,  the  output  value  of  u  depend*  only  on  the 
Input  value  of  tr.  Thus,  (t-.u)  €  l’v  if  and  only  if  o  a  u.  This  results 
in  IVa  i. 

Other  relations  are  obvious  as  there  l*  no  assignment  in  a  null 
statement  and  all  the  variables  of  the  program  P  are  preserved.  Thu*. 
MOD  a  d.  PUB  =  l',  Sv  a  d.  and  Vs  a  <S. 

G.2  Assignment  Statement 

Por  an  assignment  statement, 

*:  v expr; 

t>  is  the  only  variable  that  is  modified  and  il  depends  on  all  the 
variable*  appearing  In  the  expr  part  of  the  statement.  Therefore, 
PIIE  =  P  -  {v),  MOD  a  {oj,  and  relation  )>V  =  ((5.u)ln  £  expr) 
The  output  value  of  variable  v  depends  on  the  execution  of  statement  * 
so,  \’s  a  {(tt,»)).  The  relation  l\-  can  be  obtained  by  using  equation  & 
IV  =  {(o, u)|u  €  erpr)  U  {(u, u)|u  G  P  -{«)}. 
that  is  equivalent  to: 

Pl<  a  {(u,  u)|u  e  expr)  U  (r  -  (u,  v)). 
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(.3.1  Sequence  of  Statement* 

Earlier  the  relation*  have.  been  defined  for  program*  containing  single 
***ignt>Knl  and  null  statement*.  Definition*  for  loop  Mil  conditional 
statemenU  are  provided  later.  Proeedutc.  *«d  function  call*  c»n  be 
accommodated  by  considering  them  u  generalised  assignment  state- 
menu,  These  bank  definition*  can  b«  u*cd  to  tcmsituct  rcUtion*  foe 
programs  containing  multipk  statemenU  where  the  program  I*  visual. 
I>«4  a*  a  finite  sequence  of  Msietiwnt*.  Sines  these  relation*  satisfy  tbs 
associativity  rule.  U  I*  sufficient  to  show  bow  to  generate  relation*  for 
a  sequence  of  two  program*.  Using  Induction,  a  program  of  arbitrary 
site  can  be  analysed  and  relations  can  be  constructed. 

Consider  tbe  sequence  P  of  two  program*  Pi  and  /S.  where  all  the 
three  relations,  IV.  St<and  tg  aeeknown  for  each  of  l\  and  P3.  For  the 
sequence,  PRF/  **  PREr‘  n PRE**1  and  MOD'1  ■  MOD^UMOD* 

It  ><  aoumed  that  both  l\  and  Pi  have  single  entry  and  exit  poinU. 
Now  (s,  t>)  €  S{!  if  any  of  the  following  two  condition*  hold 

I,  The  statement  *  i*  In  /\  and  iu  execution  u»e*  (depend*  on)  the 
input  value  of  variable  >•;  f.e.,  (*,»-)  6  ■?£'. 

3.  Tbe  statement  s  I*  in  l\  and  It  depend*  on  the  Input  value  of 
variable  u  and  the  output  value  of  variable  w,  after  Plt  depend* 
on  the  input  value  of  variable  u  before  P\ .  This  i*  equivalent  to 
saying  that  (*,u)  €  and  (u,v)  G  \\f‘. 

Thus, 

■  t\f'  (f.) 

Similarly,  the  relation  Vg  can  be  obtained  for  the  program  P. 

VfnVpUXp.X?  (7) 

Finally,  equation  5  can  be  used  to  determine  IV. 

v,r  a  v i  -  s$  u  (/>£<  n  ip)  a . =  vf* .  vf  (?) 

0.3.3  Compound  Statement* 

The  dependence  relations  can  also  be  determined  for  compound  state- 
tnenU.  However,  unlike  assignment  and  null  sUlemcnU,  the  definl. 
lion*  are  different  for  static  and  dynamic  contexts.  For  example,  un- 
less  the  program  is  executed  for  specific  initial  values  for  the  input 
variables,  it  I*  not  possible  to  determine  whether  the  Hen  part  of  a 
conditional  will  be  executed  instead  of  the  tire  part. 

Conditional*  For  a  program  P,  having  a  tingle  if  statement, 

*  :  If  expr  then  P,  else  Pj  end; 

MOD'’  =  MOD*,  PRF/  =  I1  HE*, 

Vf  s  MOD*  ©  *  U  V/*, 

S(!  =  {s)OCONDuS*,  and 
Vf  =  Vf‘  U  (MOD*  ©  COND)  (8). 

Here  COND  denotes  the  set  of  variables  in  expr,  “<J"  is  the  carte¬ 
sian  product  operator,  and  i  could  cither  be  1  or  2  depending  on 
whether  expr  evaluate*  to  TRUE  or  FALSE. 


Loop*  Suppose  the  program  P  contain*  a  slngk  loop  statement, 
s  ;  white  COND  loop  p  end; 

If  the  loop  iterate*  for  N  +  I  time*  then: 

MOD*  ■  MO!/,  and  PRE*  si  PRF/. 

The  dependence  relations  are  »*  follow*: 

$P  »{{«)©  COND  USt.)  -  Vf  O  rV. 

Vf*  ■  (MOl/  ©  COND  U «)  -  Vf  ©  A*,  and 

V/  at  Mao'  ©  {*}  UtMOt/  ©COrVDur)- Vf  ©  A*  •  Vf. 

Here  IV ©,V«  tV.\y.....tV. 

,v 

0.3  Static  Relation* 

tn  general,  It  I*  not  possihk  to  predict  the  actual  path  of  compulation 
with  static  analysis  of  a  program.  All  control  Dow  paths  are  consid¬ 
ered  whtk  generating  these  dependence  relations  for  static  projection*. 
With  stalk  analysis  only,  for  (v,*)  G  Vf  the  final  value  of  vatlabk 
u  after  exceutlag  program  P  may  depend  on  the  cxeeutlon  of  state- 
ment  *.  ThU  relational  approaeh  for  Malic  analytic  was  introduced 
in  (3]  and  the  definition  of  our  dependence  relation*  I*  motivated  by 
the  A,  p  and  p  relation*  of  (3]  and  their  utefutne**  In  generating  In- 
formation  about  live  variable  analysi*,  redundant  code  elimination, 
expression  movement  and  generation  of  partial  statement*  (concep¬ 
tually  similar  to  ilttie  program  projections).  These  relations  can  be 
generated  by  parting  the  program  text  and  identifying  all  variable*, 
statemenU,  structure  of  all  compound  aiatcmcnU  and  the  sequencing 
of  statements. 

6.4  Dynamic  Relations 

Tile  dependence  relations  that  were  defined  for  static  analysi*  arc  also 
useful  during  the  dynamic  execution  of  a  program  with  actual  value*. 
Dynamic  projection*  can  he  mote  precise  a*  the  actual  trajectory  of 
the  program  execution  is  also  avallabk  to  the  analyser. 

We  describe  a  procedure  that  generate*  tbe  dynamic  dependence 
relations  foe  the  program  P  a*  it  executes,  under  the  control  of  the 
analyser.  This  procedure  is  called  by  tbe  analyser  after  executing  each 
statement  of  P.  An  interna)  stack  is  maintained  by  the  procedure 
fur  processing  compound  statemenU.  The  generator  maintains  tbe 
dependence  relations  for  the  part  of  the  program  that  ha*  already  been 
executed.  This  information  k  preserved  between  any  two  invocations 
of  (hi*  procedure. 

Tbe  stack  can  store  the  following  item*: 

1.  statement  type 

2.  expression  expr  for  if  and  loop  statemenU 

3.  dependence  relations  tv,  v,  and  t, 

4.  seU  Mod  and  I’re 

Pre-Processing 

Initialise  the  dependence  relation* 

«.  =  *; 

V,  =  4i 

*.  =  4; 

Mod  =  d; 

Pre  =  V; 

procedure  DynamicDependcnceGenerator(s:in  statement) 
begin 
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CM)*  b 

wlum  ■> 

update  *., 
update  Mod  »nd  I’te. 

wHc«  brgin-of  => 

pu»h  *uiemcnt.type; 
pu»l)  ttfr  part  of  if  tx  loop  utalerorel, 

pU*h  *Vi  I’m 

pu*h  Mod  Mid  I’re; 

Initialise  new  *,Mid  v,; 
initialise  ik*  Mod  Mid  Pic; 

whe«  end-of  i/-»r.b«p-)(«l<m<*(  ■> 
complete  the  relation*  from  Ok  current 

v»|ik*  Mid  tep-mo*t  entry  (for  <*pr,  Mid  type), 
unstuck  the  top-meat  entry  Mid  male  it  current, 
update  cuttcnl  (elation*  with  the  recently 

completed  (elation*  for  a  compound  statement; 

end  cam; 
end; 

6.5  Example 

Coadder  the  protram  that  generate*  fibonat:!  number*  for  which  the 
dependence  relation*  and  projection*  are  provided  hetow. 

procedure  libon*cci((0,  fl.  n:  in  integer;  fibo:  out  Integer)  i* 
fnl.fn5.fn.  Integer, 

I:  Integer; 

Iregiu 

if  (  n  >  1  )  then  •  •  it 

fnl  :a  fO;  • .  »j 

fn2:=fl; 

1  :=  3; 

whihj  ( i  <=  n  )  loop  •  -  »» 

fn  t=  fnl  +  fnl;  •  •  *< 

fnl  :s  fn?;  •  • 

fn?  ;a  fn;  •  •  n 

i  :=  I  +  1;  -  •  $t 

end  loop; 

cite 

fn  :=  .1;  • .  t,B 

end  if; 

fiho  :=  fn;  •  -  in 

end  fibonacci; 

0.3.1  Static  Relation* 

For  the  fibonacci  program: 

MOD  ={fibo,  Tn,  fnl,  fn2,  i ),  and  PRE  ={n,  fO,  fl) 

Sv  ={(l.n).  (2,10),  (3/1),  (5,n),  (0,f0),  (C.fl),.(7,fD), 

(7,n),  (8,(0),  (8,fl),  (11,10),  (ll,fl),  (ll.n)) 

VV=  {(fibo.l),  (fibo,?),  (fibo.3),  (fibo, 4),  (fibo,5),  (fibo.O),  (fibo, 7), 
(fibo,8),  (fibo, 9),  (fibo, 10),  (i,l),  (i,4),  (i,5),  (1.9), 
(fn,l),(fn,2),(fn,3).(fn,-t),(rn,5),(fn.0),(fn,7).(fn,8),(fn,9)l(fn,10), 


(fnl.t)<(rnl.2).(fnl^),(fnl,d),(fnl,S).(fnl,6),(fnt.7),(fntJI),(fnl.9), 

(fn?.l),(fn2,2),(fn?^),(fn3,4),(fn?.3),(fn2>«).(fn3<7),(fn3^).{fn?,9)) 

IV*  {{fibo,  10),  (fibo/i),  (fibo,n),  (fn,f0),  (fn,fl),  (fn,n), 

(fnl.ro).  (fnl /l),  (fnl, a).  (fn3,IO).  (fn3.fl).  (fn?.n), 

(i*).  (U).  (n.n).  (ro.ro).  (fl.fl).  (fnl, fnl).  (fn?.fn?)) 

Thoe  relation*  explicitly  tpecify  that  n,  10  and  fl  arc  input  v»ri« 
able*  and  arc  not  modified  by  tbc  program.  The  relation  IV  can  be 
u*ed  to  generate  program  projection#,  Foe  example. 

P} .  *  (1.C.J.9)  that  represent*  tbe  program: 

if  (n  >  1 )  then  ••*! 

I  :■  3;  •  •  *, 

whUo  ( i  <■  n )  loop  *  ■  #* 
i  a*  i  +  I;  •  • 
end  loop; 
end  if; 

8.3.2  Dynamic  Relation* 

Suppose  tbe  fibonacci  program  I*  being  executed  for  n  *  I.  ‘Hie  de¬ 
pendence  relation*  foe  the  program  Me  more  precite  when  the  program 
execution  infocmalien  ia  available  to'ihe  dependence  relation*  gener¬ 
ator.  Foe  tbi*  Input  value,  atatement*  1,  10  and  II  will  be  executed 
and  MOD  *(fn,  fibo).  and  l’RE  nV- MOD.  The  relation*  ate; 

^1’  ={(liR)i  (Dr1))i 

IV  “I (fibo.l),  (fibo, 10),  (fibo, 11),  (fti.l),  (fn.lO)),  and 
IV  *((fibo,n), (fn.n), (10,10), (fl,n),(n,n), (fnl, fnl), (fn?.fn?), (1,1)). 

For  tbi*  execution,  ffi*  n  (1,10,11),  tocrnpoitding  to  the  pro¬ 
gram: 

if  (  n  >  I  )  then  •  •  *1 
null; 
cl»« 

fn  a*  -1;  -  -  #|Q 

cud  if; 

fibo  fn;  >  >  *n 

While  debugging,  if  the  output  value  of  the  variable  fibo  l*  erro- 
neou*  then  only  three  *tatemenU  Me  to  be  contldered  foe  finding  the 
caute  of  the  error. 

7  Visibility  and  Control  Flow  Graphs 
for  Ada 

Using  the  formalism  developed  In  cMlicr  sections,  the  language  depen. 
dent  definition*  can  be  provided  for  Ada.  Ada  ute*  linear  elaboration, 
implicit  and  explicit  nesting,  and  package*  with  ipecial  visibility  ex¬ 
port  and  import  mechanism*.  For  example,  a  declarative  context  in 
Ada  can  be:  (peeification  and  body  of  procedure*,  function*  and  pack¬ 
age*,  and  the  block  statement.  Wit)  in  a  declarative  context,  the  unit* 
correspond  to:  vMiablc,  type  and  ■  -nitant  declarations;  (iiignmcaf, 
i/  and  hof  statements;  procedure  calls;  and  expressions  (including 
variables  Mid.  function  calls). 

7.1  Visibility  Flow  Graphs 

Suppose  a  declarative  context  Af  directly  nests  ,V  after  unit  i— I  where 
N  is  not  a  package.  Nodes  Af  and  N,  and  the  Me  (Af,  Af)  are  added 
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Figure  I:  AdaAnr  An  Ad*  Program  Analyser 


to  the  IVG.Tbe  function  OtT(v...V|  ■  l',M  »»d  /A'(x/,.v,i  •*  t.  A* 
there  it  no  viability  How  from  the  context  ,V  to  Af.  *r«  (A’.Af)  it  pa 
added  to  the  graph. 

For  explicit  netting,  ruing  separate  and  u  separate  clauses,  the 
definition*  for  IN  and  OlTore  the  tame  However,  the  connection  of 
the  node*  N  and  Af  with  the  are  (A(.A')  i*  postponed  to  the  linking 
phase  when  individual  VFG»,  corresponding  to  ditferenl  library  unit*, 
arc  linked  together. 

If  the  context  A'  it  a  package  then  there  it  an  are  (A’.Af)  denoting 
the  flow  of  visibility  from  the  public  part  of  the  package  A’  to  iu  parent 
A I.  If)  i*  the  last  unit  iu  the  public  part,  then  OLr!\s,.U)  «*  '"/V  At 
the  target  of  thlt  ore,  /Aj^.m.j  “  t 

The  package*  can  be  used  aero**  the  library  unit*  uring  the  \nlk 
dame.  If  entity  I  u*e*  the  package  N  with  a  tri/A  elauie,  rhe  assoei. 
ated  visibility  flow  it  represented  by  the  are  (A'.Af )  The  IN  and  OVT 
relation*  ate  the  tame  a*  for  the  are  (A’.Af)  a*  described  before  for  Af 
netting  the  package  A’.  As  for  explicit  netting,  ara  corresponding  to 
the  uilA  daute  are  Kl  ii[  t  the  Vh'tit  corresponding  to  all  library 
module*  have  been  conn  ed.  The  set*  t\  and  It,  are  defined  for 
the  varlou*  tyjies  of  units  i  isble  1 

7.2  Control  Flow  Grnplt 

Control  flow  graph*  for  Ada  program*  with  if  and  loop  statement* 
are  defined  using  the  primitive*  displayed  in  table  2. 

8  Implementation  of  an  Ada  Program 
Analyzer 

Currently  we  are  in  the  process  of  implementing  an  Ada  Program 
Analyser  [AJaA  n)  ,  Here  the  design  of  A  if  a  An  u  outlined,  ,v,d  the 
functionality  of  its  main  components  is  discussed.  The  system  is  he* 


ing  implemented  on  Sun  workstations  using  Unix’/C  platform  and 
tool*  like  Lex,  a  lexical  analyser  generator  and  Yacc,  an  LAI.R  parser 
generator. 

8.1  VFG  Generator 

The  VFG  for  a  program  is  generated  in  a  bottom-up  fashion.  The 
grammar  of  Ada  is  described  in  the  Yace  notation.  Currently  only  a 
representative  subset  of  Ada  has  been  targeted. 

Attributes  can  he  deflaed  for  each  node  of  the  parse  tree.  For  a 
VFG,  this  is  used  to  generate  the  unltdist  and  information  for  the 
VFG  edge*.  At  the  expression  level,  the  II  sets  are  the  only  attributes 
a*  the  D  lets  are  always  empty.  Whenever  a  production  correspond, 
ing  to  a  declarative  context  reduces,  the  unit-list  Is  ready  and  can  be 
attached  to  the  header  (newly  created  for  the  recently  Identified  eon. 
text).  While  analysing  a  compilation  unit,  the  intra-unit  VFG  arts 
are  fully  determined. 

The  VFG-GKN  comjionenl  takes  a  program,  generates  the  VFG, 
and  when  all  the  progiams  have  been  transformed,  link*  the  individual 
VFCt  together.  The  linking  phase  provides  resolution  for  all  the  un> 
resolved  names  In  u  separate  and  trill  clauses.  An  u  separate  clause 
require*  a  corresponding  separate  clause  in  a  subunit.  Similarly,  the 
trift  clause  needs  a  package  that  Is  implemented  a*  a  separate  compi¬ 
lation  unit.  If  the  package  specification  and  the  corresponding  body 
are  implemented  as  different  compilation  unit*  (the  specification  a*  a 
library  unit  and  the  body  a*  a  secondary  unit),  they  are  also  linked 
together  with  a  VFG  are. 

After  the  linking  phase,  there  are  two  types  of  VFG  arcs.  The  are 
AJiEST  corresponds  to  traditional  nesting  in  block  structured  Ian- 
guage*  and  signifies  a  uni-directional  flow  of  visibility  from  the  parent 
to  its  child.  To  accommodate  packages,  the  are  A.I’ACK  link*  a 
package  to  another  declarative  context  describing  the  visibility  of  the 
package  name,  and  eventually  the  non  private  declarations  of  that 
package. 

,lfnis  If  a  Iratlcnuik  of  ATXiT 
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t.t.l  Internal  mill  External  Data  Structure  fur  VFG» 

Internally,  l(tt  VPlt*  mg  reprinted  u.mg  pointer*  and  structure* 
Karh  declarative  rente*!  correspond*  to  a  structute  with  fir  14*  to  Mots 
iu  10,  M«',  /a/bvswr,  l*|ic.hsr,  til  Jut  and 

»*it*.  A  li»l  l*  maintained  for  both  Incoming  and  outgoing  IVtf  ate*. 

The  WG  representation  can  be  transformed  for  di*k  stwage  A 
U*p  tike  notation  t*  u«t4  with  balanced  parenthesized  li»t*.  Thu  rep¬ 
resentation  will  houseful  for  t  hr  incremental  analysts  of  large  programs 
where  only  the  modified  routes  file*  Me  reprocessed. 

8.2  Dependence  Relation*  Generator 

Tbtee  unit*  norther  comprise  the  dependence  relation*  generator  Ik" 
pendente  relation*  for  a»*!gnmen.  statement*  can  hr  generated  directly 
from  the  syntax  tree  of  the  ptogtam*.  For  compound  *iaicroenU,  infor¬ 
mation  shout  the  uateimnt  type*.  an4  structure  of  e*p tewalon*  can  be 
prepackage  Thi*  U  petformed  by  the  /Vt./Woicr,  a«4  iu  output 
U  used  to  generate  relation*  in  both  italic  an4  dynamic  context*.  In 
the  italic  lituatioo,  IDUT-Sflkpendeuce  Hclaiiou*  Generator  In  Static 
Context)  require*  information  only  from  the  preprocessing  mil-  How. 
ever,  for  OKG-O,  information  from  the  A4a  interpreter  i*  also  heeded 
to  that  the  actual  program  trajectory  U  utilited  for  generating  depen. 
dence  relation*, 

8.3  Utter  Interface 

The  functionality  of  the  u*er  interface  i*  divided  into  two  part*  deal, 
ing  with  the  *tatic  and  dynamic  aspect*  of  the  program  lemantic*. 
VI~S  (Uier  Interface  for  Static  Semantic*)  implement*  a  browxing  tool 
luppocting  crow. referencing,  viability  and  scoping  propertie*.  and  in¬ 
formation  generated  from  the  italic  dependence  relation*. 

Tbe  VI’D  component  handle*  the  dynamic  lemantic*  of  program*. 
Traditional  debugging  can  be  aupported  by  *upplctiKntlng  tbe  inter¬ 
preter  with’*  break-point  and  display  facility.  This  debugging  proem 
i*  Improved  by  uiing  the  dependence  relation*  generated  by  OUG-D 

9  Program  Maintenance 

Tlie  primary  motivation  for  thi*  work  U  to  facilitate  the  development 
of  analytic  tool*  for  supporting  program  maintenance.  In  tbe  main, 
tenance  pha*e,  a  i mailer  number  of  programmer*  are  available.  The 
original  development  of  the  program  may  have  involved  mu'e  indivrd- 
ual*  for  developing  different  part*  of  tbe  program.  Tbcrciote,  effective 
decomposition  tchcme*  and  tuitable  browsing  tool*,  to  facilitate  com¬ 
prehension,  are  more  important  for  program  maintenance.  Support 
for  debugging  and  verification  U  alto  needed. 

9.1  Program  Comprehension 

Croat  reference  generator*  are  useful  to  extract  Information  from  pro¬ 
gram  text*.  Tbe  VFC  bated  interface  produce*  thi*  information  in  an 
on.detnand  fashion  and  portray*  tbe  full  visibility  rule*  of  tbe  language 
For  large  programs,  thi*  Is  more  effective  compared  to  a  comprehensive 
listing  of  tbe  erot*  reference  information.  Furthermore,  other  type*  of 
secondary  information,  arising  from  the  transitive  nature  of  many  tela- 
lionthips,  are  not  directly  present  in  tbe  listing.  On  tbe  other  hand,  the 
interactive  interface  is  ideally  suited  for  these  special  types  of  queries, 
without  inundating  the  user  with  unrequested  information. 


9.2  Program  Debugging 

Program  ilicing  (l!)  was  shown  to  be  Useful  fot  program  debugging 
a*  one  can  automatically  identify  only  thewe  program  statement*  that 
may  have  been  used  foe  determining  tbe  current  value  of  tbe  van. 
able  under  consideration  Partial  statement*  |J)  and  s«at*e  -tegtam 
projections  are  similarly  useful  for  tht*  type  tf  debugging. 

In  the  I'KLAS  (7)  system,  both  static  and  dynamic  analyse*  have 
he*ir  employed  to  produce  dependence  network*  that  can  Identify  the 
statement*  whroe  execution  result*  In  the  curtenl  (and  erroneous) 
value  of  the  variable  under  consideration.  Tbe  system  maintain*  the 
entire  trajectory  of  tbe  program;  a  single  statement,  if  executed  sev¬ 
eral  times.  ti*ay  correspond  to  multiple  nodes  in  the  trajectory.  Tbe 
dynamic  program  projection*  also  utilise  the  program’s  trajectory  hut 
maintain  the  analyst*  information  a*  dependence  relations  of  fixed  sire. 
However,  they  ate  more  precise  than  static  projections  or  program 
slices 

9.3  Program  Testing 

It  Is  possible  to  utilise  the  dependence  relation*  to  simplify  program 
testing  associated  with  maintenance.  Suppose  the  output  value  of  a 
variable  o  I*  to  be  studied  while  the  program  U  being  tested,  ‘tills 
variable  could  be  a  new  one,  just  recently  included  In  tbe  program 
during  maintenance  From  the  static  dependence  relation  IV.  one  can 
determine  all  the  variable*  such  thel  the  output  value  of  v  depend*  on 
the  Input  value  of  these  variable*  Only  these  variable*  need  effective 
input  value*  and  l.ic  corresponding  program  projection  can  be  exe¬ 
cuted  foe  debugging  purpose.  Thus,  only  the  relevant  pm l km  of  the 
program  requires  to  be  tc*ted. 

9.4  Fomin!  Verification 

Dependence  relation*  may  also  be  useful  in  formal  proof*.  Suppose 
it  U  required  to  prove  a  particular  assertion  that  Involve*  only  some 
of  the  program  variable*  (may  be  those  which  arc  recvutly  introduced 
during  program  maintenance).  Instead  of  considering  the  effect  of 
the  entile  program  on  Initial  assertions,  the  dependence  relation*  can 
be  used  to  Identify  all  input  variable*  and  statement*  on  which  the 
assertion  to  be  proved  depends  Thi*  eoulJ  especially  be  effective 
during  program  maintenance,  where  a  procedure  U  modified  to  add  a 
functionality  that  l*  entirely  unrelated  to  the  old  functionality  of  the 
procedure.  A  procedure  may  contain  two  groups  of  statement*  that 
do  not  interdepend  on  each  other.  Such  modification*  are  typical  in 
the  maintenance  phase. 

10  Concluding  Remarks 

Our  work  is  aimed  towards  the  identification  of  decomposition  scheme* 
applicable  towards  the  static  and  dynamic  analyse*  of  programs  We 
provide  the  visibility  How  graphs  a*  an  intermediate  representation 
form  for  static  analysis  of  multi.module  programs.  Helations  are  de¬ 
fined  to  capture  the  interdependence  among  variable*  and  statements 
of  a  program  in  both  static  and  dynamic  context*.  These  relations 
are  used  to  identify  and  generate  program  projections,  and  other  use¬ 
ful  information  for  debugging,  testing,  and  program-proofs.  A  proto¬ 
type  analyzer,  called  4 da, In  has  been  designed  that  incorporates  these 
schemes  for  analysing  Ada  programs. 
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*I1»«  implementation  of  Ad*A»  is  continuing  M©*l  ef  the  compo¬ 
nent*  ef  the  Prr.Pnrwstr  including  l he  lexical  analyiec.  lh«  parser, 
and  (he  VFG  generator  have  been  implemented  Algorithms  fee  gm- 
crating  the  dependence  relation*  fee  static  and  dynamic  situations 
have  been  dcwJoped  and  ate  rotf*nlly  being  implemented  Hie  uset- 
interface  is  partially  completed  so  that  the  VfG  inhumation  can  lx 
displayed.  On  the  theoretical  side,  the  usefulness  ef  the  dependence 
relation*  fee  toting  and  proving  program*  t*  being  further  explored 
and  formalised 

We  envbion  that  the  current  work  can  tie  extended  along  the  fol¬ 
lowing  lino. 

•  Augmenting  the  AdaAn  functionality  with  support  fee  test  an4 
proof  maintenance 

•  Implementing  an  analyxer  for  the  full  Ada  hanguage  with  arbi¬ 
trary  control  flow  (goto’*),  exceptions,  recursion  an4  tasking 

•  Using  4epen4ence  relation*  to  trr'.mtlute  the  existing  program* 
foe  simplifying  future  maintenance- 

•  Extending  this  approach  for  analyting  parallel  program*. 

•  Verifying  the  scope  and  elTccti  wne**  of  *uch  an  analyicr  for  pro¬ 
gram  maintenance  in  production  environ  menu 
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Abstract 

A  real-time  embedded  system  is  typically 
characterized  by  its'  ability  to  dynamically  change 
the  priorities  of  its'  concurrently  executing 
processes.  Furthermore,  processes  with  high 
priorities  must  be  selected  to  execute  in  (avor  ol 
those  with  lower  priorities  to  ensure  that  system 
requirements  have  been  met.  Ada  does  not 
directly  support  dynamic  priorities  in  that  Ada 
tasks  are  assigned  static  priorities  at  compilation 
time.  However,  we  will  illustrate  how  to  utilize 
Ada’s  tasking  (eatures  to  provide  (or  dynamic 
priorities. 

It  is  a  proven  (act  that  Ada’s  definition  (or  priority 
scheduling  has  severe  deliciencies  when 
utilized  in  hard  real-time  environments. 
Nevertheless,  there  is  nothing  prohibiting  the 
software  engineer  from  implementing  his/her 
own  scheduling  algorithm.  As  a  case  study  we 
developed  an  application  in  Ada  that  simulates  a 
simple  operating  system.  Our  approach  not  only 
supports  dynamic  priorities  but  also  provides  an 
innovative  way  to  handling  the  deliciencies  in 
priority  scheduling. 


The  purpose  of  this  experiment  was:  1)  To 
provide  an  innovative  approach  to  simulating  a 
simple  real-time  system  in  Ada;  2)  To  use  Ada 
tasking  (or  implementing  a  dynamic  priority  task 
scheduling  algorithm;  3)  To  demonstrate  the 
feasibility  ol  using  an  object-oriented  approach 
(or  developing  real-time  systems;  4)  To  dispel 
the  belief  that  Ada  supports  only  one  task 
scheduling  algorithm  (i.e.,  The  one  supplied  by 
the  compiler  vendor). 


Ada  and  Real-Time  Systems 

Many  Ada  advocates  have  voiced  their  concerns 
on  the  problematic  features  of  Ada  in  real-time 
applications.  Needless  to  say,  these  concerns 
are  mostly  focused  on  the  inadequacy  of  Ada  in 
addressing  critical  timing  issues  in  applications 
where  meeting  most,  if  not  all,  deadlines  are 
probably  the  most  paramount  aspects. 

Most  experts  believe  that  the  “real  time 
scheduling  work ...  is  concerned  with  separating 
timing  issues  from  logical  correctness  Issues  in 
real-time  system  design.  In  current  practice, 
these  Issues  are  intertwined  to  the  extent  that 
program  structure  is  dominated  by  timing  issues 
rather  than  issues  of  modifiability,  maintainability, 
understandability,  etc."1 

An  Object-Oriented  Approach 

An  Object-Oriented  Design  (OOD)  methodology 
was  used  to  develop  the  simulator,  rather  than 
the  traditional  top-down  functional 
decomposition  approach.  Realizing  that  Aoa  is 
not  an  object-  oriented  programming  language, 
we  felt  that  we  could  view  the  problem  space 
from  a  more  realistic  perspective  as  a  collection 
of  objects  and  associated  operations.  Each 
module  in  the  software  system  denotes  an 
object  (abstract  state  machine)  or  class  of  objects 
(abstract  data  type).  Each  object  in  our  operating 
system  simulator  was  implemented  as  an  Ada 
task.  Depending  on  the  "functionality"  of  the 
object.  It  could  be  implemented  as  a  server  task, 
an  actor  task,  or  an  agent  task.  For  instance,  a 
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CPU  object  is  considered  as  a  server  task  i. 

because  it  does  not  "act"  on  other  task  objects. 

A  process,  on  the  other  hand,  is  an  actor  task 
because  it  must  periodically  make  a  request  lor 
service. 

Operating  System  Simulation2 

As  mentioned  belore,  the  experiment  was  the 
implementation  ol  a  simple  operating  system 
simulator.  The  simulator  was  to  provide  at  least 
the  following:  1)  Allow  (or  dynamic  priorities;  2)  ii. 

Allow  (or  multiple  RAM's,  CPU's,  lOP's,  Disks, 
and  Files;  3)  Allow  simultaneous  disk  access;  4) 

Allow  multiple  Read  Access  of  liles. 


A  process  is  initially  assigned  a  priority.  Depending 

on  how  busy  the  CPU  is,  a  process  may  have  to 

spend  a  lot  of  time  waiting  for  the  CPU.  Ada's  FIFO 

task  entry  scheduling  is  not  adequate  to  prevent 

starvation.  Thus,  another  approach  was  taken.  First, 

the  longer  a  process  waits  for  a  CPU  (or  other  iii. 

resources),  the  higher  its'  priority  becomes  (also 

known  as  "aging").  After  a  sendee  lias  been  granted, 

the  process's  priority  will  have  to  be  reset  to  its' 

initial  priority  to  prevent  it  from  indefinitely 

postponing  other  processes  for  services.  Second, 

"Families  of  Entries"  were  used  to  implement  a  task 
scheduling  algorithm  which  is  not  strictly  FIFO. 

Because  a  task  entry  has  its'  own  sendee  queue,  a 

family  of  entries  in  effect  is  a  very  close  iv. 

approximation  of  a  multiple  feedback  queuing 

approach.  This  approach  allows  a  process  with  a 

higher  priority  to  be  serviced  prior  to  any  other 

processes  with  a  lower  priority  even  though  the 

higher  priority  process  arrived  at  a  later  lime. 

Our  operating  system  consists  of  the  following 
resources:  Central  Processing  Units  (CPUs), 
Random-Access  Memories  (RAMs),  Input-Output 
Processors  (IOPs),  Secondary  Storages  (Disks),  and  v. 

Disk  Files  (Fites). 


In  this  simulation,  we  adopt  the  following  resource  vi. 

allocation  rules: 


A  complete  source  code  listing  of  the 
simulation  is  available  upon  written  request 
addressed  to  either  author. 


Resources  arc  altocatcd  based  on  the 
priority  of  the  requesting  process. 
High-priority  processes  will  always 
be  preferred  over  low-priority 
processes.  If  two  processes  of  the 
same  priority  arc  competing  for  a 
resource  simultaneously,  then  the 
choice  becomes  arbitrary. 


RAMs:  Each  RAM  will  have  ten 
equally  sized  slots  for  processes. 
All  processes  occupy  the  same 
amount  of  RAM  space.  There  is  no 
RAM  preemption.  Once  a  process 
gains  access  to  a  RAM,  it  will 
remain  there  until  completion. 
Further,  processes  do  not  do 
dynamic  memory  allocation. 


CPUs :  The  number  of  CPUs  is 
allowed  to  vary.  We  ran  the 
simulator  with  one,  two.  three, 
four,  and  five  CPUs.  CPU 
preemption  takes  place  after  a 
process  has  been  running  for  ten 
consecutive-  time  units. 


IOPs:  An  IOP  manages  accesses  to 
a  disk.  Before  a  process  can  access  a 
file  on  a  disk,  it  must  first  gain 
access  to  an  IOP.  More  than  one 
I/O  operation  can  occur  at  the  same 
time,  but  not  to  die  same  disk.  IOP 
preemption  is  not  allowed. 


Disks:  Our  operating  system 
consists  of  four  disks,  each  of 
which  contains  four  disk  Files. 

Files:  A  File  is  identified  by  its 
name  with  the  following 
convention:  FilcNumbcr- 
DiskNumber ,  c.g.,  file  til  on  disk 
#3  is  named:  F1D3.  A  process  may 
have  the  following  types  of 
accesses  to  a  file:  read-only  or 
write-only. 
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Once  a  process  gains  access  10  a  RAM,  it  performs 
two  types  of  requests:  CPU  and  !0.  A  CPU  request  is 
always  followed  by  an  10  request,  and  vice-versa.  The 
length  of  each  activity  is  randomly  generated.  For 
simplicity  (and  to  avoid  polling),  each  process  is 
assigned  to  specific  CPU  and  IOP.  A  fair  algorithm  is 
used  to  assign  equal  number  of  processes  to  each 
CPU  and  IOP.  External  events  and  interrupts  arc 
simulated  by  using  various  rendezvous  mechanisms. 


Process  Life-Cycle 

When  a  process  arrives  into  the  system,  it  must  then 
compete  for  a  RAM  space.  (In  order  for  a  process  to 
be  able  to  run,  it  must  reside  in  eorc.)  Since  we  only 
have  one  RAM  which  will  only  hold  ten  processes, 
some  processes  will  likely  have  to  wait  for  a  RAM 
space.  Once  a  process  is  in  core,  liven  it  can  be  in  one 
of  the  following  states: 


i.  Running.  A  process  is  running 
cnee  it  has  gained  access  to  its 
assigned  CPU. 

i  i.  Blocked  for  an  IOP.  A  process  is 
blocked  for  an  IOP  if  it  is 
requesting  to  do  an  1/0  and  there 
are  no  available  lOPs. 


iii.  Blocked  doing  I/O.  A  process  is 
blocked  doing  I/O  after  it  has 
gained  access  to  an  IOP,  the  disk 
where  the  file  resides,  and  to  the 
file  itself. 


iv.  Ready.  A  process  is  in  a  ready 
suite  when  it  is  waiting  to  gain 
access  to  a  CPU.  A  process  can 
be  in  a  ready  suite  after  it  has 
gained  access  to  a  RAM  space, 
after  its  lime-slice  has  expired,  or 
after  completing  an  I/O  burst. 


Since  an  object-oriented  approach  is  used,  the 
traditional  concept  of  a  scheduler,  or  cyclic  executive, 
is  absent  from  our  simulator.  A  process  is  an 
intelligent,  yet  obedient,  object.  On  one  hand,  it 
knows  when  to  wait  for  a  CPU,  when  to  access  a  file, 
or  when  to  release  an  IOP.  On  the  other  hand,  it 
always  abides  by  the  rules  given  earlier. 


Process  Class 

Traditionally,  a  scheduler  would  be  responsible  for 
creating,  dispatching,  and  terminating  processes.  In 
our  design,  liowcvcr,  processes  arc  represented  as  Atla 
tasks  which  will  communicate  directly  with  resources 
such  as  CPUs,  RAMs,  lOPs,  and  so  on.  CPU  ami 
I/O  bursts  arc  simulated  by  using  a  delay  statement. 
Although  a  delay  statement  is  known  to  be  an 
inaccurate  liming  mechanism,  it  is  considered  to  be 
appropriate  for  our  solution  because  of  portability 
reasons.  Finer  resolution  liming  can  be  used  instead  if 
the  environment  provides  an  external  clock  and 
interrupt. 


package  Process  is 
type  State  is 
{Blocked_For_Filc, 
Blockod_For_XO, 
Blocked_Doing_IO, 
Ready, 

Running) ; 

•  •  • 

task  type  Class  is 

entry  Start; 
entry  Stop; 

end  Class; 

end  Process; 


package  body  Process  is 
task  body  Class  is 
begin  —  Class 
accept  Start; 

—  synchronize  with  the  kernel 
—  The_Memory. 
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Seize (ThcJPriority) ; 
Until_No_Horc_Rcquoscs : 
for  Indox  in  Thc_RcqucsC3' Range 
loop 

case  The_Rcquosts (Index) . 

Kind  is 
whan 

Request . CPU_Request  »> 

a  •  * 

—  simulate  round-rebin 
•  •  • 
whan 

Request . IO_Opon_Read_Roquo3t 
whan 

Request . IO_OpcnJWrito>_Requo3t 

•  a  a 

whan 


whan 

Requost . IO_Close_Requost  -> 

a  a  a 

and  casa; 

and  loop 

The^Mcmory . Release; 

accapt  Stop; 

—  synchronize  with  the  kernel 

a  a  a 

and  Class; 
and  Process; 

NVc  chose  to  implement  Process  in  a  round  robin 
(RR)  fashion.  This  scheduling  discipline  remedies  the 
somewhat  indiscriminate  behavior  of  the  First-In 
First-Out  (FIFO)  strategy.  The  basic  idea  of  an  RR 
scheduling  discipline  is  that  the  server  (in  our  case, 
Process)  is  allocated  to  a  job  only  fora  time  quantum 
of  fixed  length  (in  this  case,  ten  time  units).  When  a 
job  mns  out  of  its  lime  slice  (quantum),  it  cycles 
back  to  the  "rear  of  the  job  queue"  to  wail  for  another 
time  slice.  In  our  implementation  of  Process,  this  is 
simulated  by  using  a  delay  statement,  a  simple 
rendezvous,  and  a  loop  statement. 

An  RR  discipline,  unlike  FIFO  can  only  be  applied 
to  a  preemptive  resource  such  as  a  CPU,  not  to  a 
non-preemptive  resource  such  as,  in  the  simulation, 
the  RAMs. 


Processor  Class 

A  processor  class,  which  is  the  parent  class  of  CPUs 
and  lOPs,  is  implemented  as  a  task  with  multiple 
entries,  one  of  which  is  a  family  of  entries.  Entries 
Stan  and  Stop  are  used  only  for  synchronization 
points  with  the  kernel. 


with  Priority; 
package  Processor  is 
type  State  is  (Idle,  Running); 

task  type  Class  is 

entry  Start; 

•ntry  Seize  (Priority. CI033) ; 

—  seizing  a  processor  is  based 

—  on  the  priority  of  the 

—  High-priority  processes  have 

—  a  better  chance  of  seizing, 
•ntry  Release; 

.  antry  Stop; 

•nd  Class; 

•  •  • 

•nd  Processor; 


package  body  Processor  is 
task  body  Class  is 

begin  —  Clas3 

accept  Start; 

—  synchronize  with  the  kernel 
Forever: 
loop 
•  •  • 

select 

accept  Seize (9); 
or 

when  (Seize (9) 'Count  ■  0)  -> 
accept  Seize (8); 
or 

when  (Seize (9) 'Count  -  0)and 
(Seize (8) 'Count  -  0)  -> 
accept  Seize  (7); 

o  r 

when  (Seize (9) 'Count  «  0)and 
(Seize (8) 'Count  =  0)  and 
(Seize (7) 'Count  =  0)  and 
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(Seize (6) ’Count  ■  0)  and 
(Seise (5) ’Count  »  0)  and 
(Seise (4) 'Count  ■  0)  and 
(Seise (3) 'Count  *  0)  and 
(Seise (2) 'Count  »  0)  »> 
accept  Sorse(l); 
o  c 

when  (Seise (9) 'Count  -  0)and 
(Seise (8) 'Count  *  0}  and 
(Seise (7) 'Count  »  0}  and 
(Seise (6) 'Count  «  0)  and 
(Seise (5) 'Count  -  0)  and 
(Seiso(4) 'Count  ■  0)  and 
(Soisc(3) 'Count  ■  0)  and 
(Seise (2) 'Count  *  0)  and 
(Seised) 'Count  «  0)  »> 
accept  Stop; 

—  stop  only  when  there  are 

—  no  more  outstanding 

exit  Forever; 
end  select; 
end  loop  Forcvot; 

•  •  • 

end  Class; 
end  Processor; 

The  select  statement  in  the  Processor  body  is 
constructed  such  that  a  high-priority  task  that  tries  to 
seize  is  always  given  a  chance  to  do  so.  Other  tasks 
with  lower  priorities  must  wail  in  their  respective 
entry  queues.  Note  that  for  this  to  occur,  these 
rendezvous  attempts  must  arrive  r,t  their  entry  points 
"simultaneously."  If  a  low-priority  task  arrives  prior 
to  a  high-priority  task,  then  die  low-priority  task  will 
always  be  given  access. 

Ada's  rendezvous  mechanism  is  strictly  FIFO.  If 
several  client  tasks  wish  to  rendezvous  widi  die  same 
entry  belonging  to  a  server  task,  then  they  arc 
serviced  depending  on  die  order  of  arrival  (regardless 
of  task  priorities).  Notice  that  this  approach  avoids 
starvation. 


In  a  real-time  system,  however,  the  goal  is  not  to 
avoid  starvation,  but  rather,  to  avoid  missing 
deadlines  (given  time  and  space  constraints).  Our 
implementation  of  the  Process  class  above  illustrates 
an  example  whereby  entry  families  arc  used  to  achieve 
the  effects  of  different  priority  algorithms  for  entry 
queues. 


Disk  Class 

We  stated  earlier  that  a  Disk  object  cannot  be 
simultaneously  accessed  by  more  than  one  process. 
Therefore,  the  Disk  class  is  simply  implemented  as  a 
binary  semaphore.  The  danger  of  using  semaphores  is 
obvious.  A  seize  operation  must  always  be 
accompanied  by  a  release  operation.  Failure  to  do  so 
lias  been  known  to  cause  a  deadlock.  (Euphemistically 
called  deadly  embraced!) 


package  Disk  is 
task  type  Class  is 
entry  Soiso; 
entry  Release; 
end  Class; 
end  Disk; 


package  body  Disk  is 
task  body  Class  is 
In_Usc  :  Boolean  :■  False; 
begin  —  Class 
Forever: 
loop 
select 

when  not  In_U30  ■> 
accept  Seise; 

In_Use  Truo; 
or 

whan  Xn_U3Q  ■> 

—  to  prevent  cheating 
accept  Release; 

In_Use  :■  False; 
o  r 

terminate; 
end  select; 
end  loop  Forever; 
end  Class; 
end  Disk; 

File  Class 

Multiple  access  to  a  File  object  is  permitted,  therefore 
wc  implemented  File  class  as  a.  counting  semaphore, 
instead  of  binary  semaphore. 

package  File  is 
type  Operation  is  (Read,  Write) ; 
task  type  Class  is 
entry  Seise  (Mode  :  in 
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•nfcry  Roloaso  (Operation)  ; 
•nd  Class; 
and  File; 


package  body  File  is 
task  body  Class  is 
N urr.be r__0 f _Re odors  ;  Natural  ;■  0; 
begin  --  Class 
Forever: 
loop 
select 

accept  Soizo  (Mode  :  in 
do 

case  Mode  is 
when  Read  ■> 
Number_Of_Roaders  :■ 

Numbe r_C f_Reado r s 

+  l7 

when  Write  •*> 
vhile  Number_0f_Reader3 
loop 

accept  Release (Read) ; 
HumbormOC_Readers  :« 

Nurrbor  Of  Readers 

-  l7 

end  loop; 
end  select; 
end  Seize; 

if  Hu:rbcr_Of_RendQrs  ■  0  then 
accept  Release (Write) ; 
end  if; 
or 

accept  Release (Road) ; 
Number_Of ^Readers  : * 
Humber__Of__Readers  +  1; 
or 

terminate; 
end  select; 
end  loop  Forever; 
end  Class; 
end  File; 


Conclusion 

Ada  has  brought  about  unprecedented  challenges  in 
various  Helds  of  software  engineering  in  general,  and 
real-time  systems  in  particular.  Object-oriented 
approaches  arc  meant  to  overcome  some,  if  not  most, 
of  these  challenges.  However,  knowing  which  Ada 
features  arc  best  applied  to  solving  stringent  real-time 
requirements  quite  often  presents  a  unique  and  yet 
familiar  problem. 


In  this  paper,  we  have  shown  several  techniques 
which  can  be  used  to  overcome  restrictions  of  Ada 
tasking.  We  arc  aware  that  current  Ada  tasking 
implementations  arc  in  general,  short  from 
captations.  Nevertheless,  we  believe  that,  in  order 
for  Ada  to  stieeced,  wc  must  proceed  with  whatever 
Ada  has  to  offer  in  solving  real-time  problems.  After 
all,  “a  journey  of  a  thousand  miles  begins  with  a 
footstep." 


References 

Booch.G.  Software  Engineering  with  Ada, 
Bcnjamin-Cummings.  2nd  Edition,  Menlo  Park, 
California,  1987. 

Dcitel,  H.  M.,  An  Introduction  to  Operating 
Systems,  Atldison-Wcslcy,  Reading,  Massachusetts, 
1984. 

EVB  Software  Engineering,  Inc.,  An  Object-Oriented 
Development  Handbook,  to  be  published  by 
Bcnjamin-Cummings,  1989. 


Notice  that  in  "accept  Seize  ...  end  Seize",  wc 
clicck  whether  a  request  is  to  Read  or  to  Write.  If  it  is 
Read,  then  wc  simply  increment  the 
Numbcr_Of_Rcadcrs.  However,  when  the  request  is 
Write,  wc  will  only  accept  Release  associated  with 
Read  until  all  current  readers  relinquish  accesses. 
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Msmer 

Many  Mi  implementation  problems  creeur  beewK  of  contention  bel»«r, 
Mi  Kwmutl  and  ihcnc  of  the  underlying  operating  system.  One  such 
problem  l*  that  the  Adi  tasking  model  It  general!/  implemented  inside  of 
a  tingle  operating  lysurn  prorex*.  Thit  carnet  nm-tiree  eonflfct  between 
the  Adi  runtime  uuk  scheduler  and  the  operating  system  process 
scheduler,  and  conceptual  conflict  between  tHc  Ada  Idea  of  lade  Mate  and 
the  operating  system  Idea  of  process »«, 

These  conflict*  load  w  operating  system  dependent  dctignt  and  toludont, 
and  a  body  of  code  that  can  be  »<  hard  to  understand  at  it  U  to  maintain. 
Solution!  of  thit  nature  are  destructive  of  the  central  Ada  paradigm. 

An  alternative  exist*:  »  ute  the  feamrea  of  Ada  to  made  the  tpcratinj 
system  dependent  pant;  to  treat  the  operating  system  process  Idee  any 
other  rctoutee  In  need  of  protection;  to  write  packages  that  arc  both  caty 
and  Intuitive  to  ute. 

We  have  taken  at  an  ymple  a  real  world  problem  dealing  with  time- 
diced  talking  and  networked  inter-process  communication!  under  die 
U.MXt  operating  system.  The  spocifieatksn  of  SockcUO  it  virtually 
Identical  to  that  of  the  standard  SequcniulJO  package,  and  avoid*  prob¬ 
lem!  of  syttem  scheduling  conflict*  within  multitasking  Ada  program*. 
At  a  bonut,  the  utility  ;t*o  opera  let  very  efficiently. 


I.  Problem 

Ada  contain*  feature*,  such  at  tasking,  that  other  language*  leave 
to  the  operating  system.  The  Ada  tasking  model  requires  close  coopera¬ 
tion  between  Ada  tasks;  the  cooperation  it  so  close,  in  fact,  dial  current 
implementations  of  Ada  under  general-purpose  operating  systems 
implement  all  Ada  talks  within  one  operating  system  process,  Ada  run¬ 
time  systems,  then,  provide  their  own  task  schedulers  to  determine  which 
Ada  task  may  run  during  the  time-slice  that  the  operating  system 
scheduler  gives  to  the  entire  Ada-based  operating  system  process. 

The  Ada  scheduler  must  maintain  the  stale  of  the  Ada  tasks  (eg., 
AWAlTlNG_RENDEZVOUS,  RUNNABLE),  and  die  operating  system 
must  maintain  the  state  of  the  Ada-based  process  (e.g.. 
AWAlTtNG.SIGNAL,  RUNNABLE).  Doing  useful  weak  In  a  program 
usually  Involves  making  calls  to  the  operating  system.  A  task  making  a 
system  call  runs  the  risk  of  puuing  the  entire  operau’ng  system  process  in 
a  non-ninnablc  state,  rather  than  simply  clanging  its  state  in  die  Ada 
scheduler.  For  instance,  a  read  call  will  put  the  UNIX  process  in 
AWAITING  SIGNAL  state,  rather  than  just  telling  the  Ada  scheduler 
that  the  task  is  in  AWAITING.RENDEZVOUS  state. 

These  problems  are  typical  of  conflicts  between  competing 
schedulers  and  compedng  ideas  of  process  state. 

When  confronted  with  these  problems,  designers  and  programmers 
must  choose  an  operating  system  dependent  solution.  Operating  system 
dependent  code  is  both  hard  to  understand  and  difficult  to  maintain.  The 

t  tNDf  il  a  tnj-aaufc  of  Bell  Ltbontoriet. 


intermixing  of  system  Independent  operational  code  with  operating  sys¬ 
tem  dependent  code  runs  against  the  grain  of  the  Ada  paradigm,  nuking 
portability  and  maintainability  mote  difficult  because  Of  the  Implementa¬ 
tion  language. 

Ckaily,  a  better  design  solution  must  caivt. 

2.  Background 

While  considering  the  Istoci  of  Operating-system  dependent  code, 
we  encountered  a  problem  in  a  multi-tasking  Ada  program  doing  network 
communication*.  Each  lime  a  task  pet  formed  a  network  re*/,  the  entire 
Ada-bored  process  would  hah.  Since  the  Ada  scheduler  for  our  compiler 
was  time-slicing,  when  the  next  timer  expiration  signal  wa*  delivered,  the 
text  was  interrupted  and  Uvkt  were  rescheduled.*  Each  re*/,  then,  had 
to  check  it*  return  status  and  determine  whether  it  needed  to  reissue 
itself.  This  caused  a  performance  lost  because  the  entire  operating  sys¬ 
tem  time-slice  was  lost  whenever  a  task  Issuing  a  taxi  was  scheduled. 
Ideally,  such  a  task  should  not  have  been  scheduled  until  ks  rexl  could 
complete.  The  alternative  w-as  to  prevent  task-switching  during  a  read. 
This  Is  unacceptable  bctausc  there  Is  no  way  Of  knowing  when.  If  ever, 
more  dau  will  be  available*  to  reaJ!  Of  course,  the  operating  system 
scheduler  could  not  know  about  the  task  (since  UNIX  Is  single  threaded), 
and  the  Ada  run  time  scheduler  could  not  know  about  the  text  call 
(since  the  text  call  was  a  system  inict free  and  not  an  Ada  prekage  call), 

3,  Approach 

Our  approach  was  “classical"  in  the  Ada  rente.  Wc  used  standard 
design  technique*  to  create  the  overall  structure  of  the  Soda  JO  utility, 
which  included  four  packages:  Soda  JO.  the  user-level  package; 
Soda,  the  system  Implementation  of  sockets:  Dauiptor,  site  abstract 
dau  type  package;  and  Syttemjnterfoce,  which  collected  tysiem-tpeeifie 
code  Including  CtayrM  Interface  code. 

In  that  light,  wo  viewed  tlie  Operating  system  process  at  Are 
resource  needing  protection.  The  Ada  technique  for  dealing  with  a 
resource  needing  protection  is  10  create  a  monitor  usk  to  arbitrate  nil 
access  to  that  resource.!  Our  Soda  package  contains  a  Dispatcher  (ask 
dot  arbitrates  all  read  calls,  and  ccttvens  them  into  render  vous.  This 
approach  also  has  the  effect  of  letting  the  Ada  scheduler  know  lieu  the 
task  Is  not  ready  to  run.  Figure  I  show*  conceptually  taw  tfds  mechan¬ 
ism  looks. 

Cemroliring  control  of  system  calls  allows  die  Ada  scheduler  to 
register  drem.  but  it  docs  not  yet  prevent  the  entire  Ada  program  from 
being  suspended  at  dre  operating  system  level  when,  say.  a  read  call  is 
made.  Tire  way  to  prevent  this  is  opiating  system  specific. 

Under  dre  Berkeley  flavor  of  UNIX,  I/O  operation*  can  be  accom- 
plislred  asynchronously  (i  e.,  an  I/O  operation  will  send  a  signal  when  it 
can  complete)  as  well  as  synchronously  (i.c.,  dre  process  will  pause  un'ul 
dre  operation  completes).  It  was  apparent  dot  to  accomplish  our  goal. 


•  Adi  Knufiiic*  for  lid  pcmui  nuny  fornu  fix  the  uhc&Jcr.  Mioy  compile  ri 

lime-ilicc  lull  —  ih*  it,  tuh  ud  rrni  ur*3  k  ttodi  o»  Ute  timer  dpi  in,  Oder  cun* 
pile rt  limply  Irt  tuh  ud  run  uufil  it  Modi.  Some  compilm  til rtf  Ute  pec* rammer  to 
duftfc  the  uKkWf/'i  ixltiYutr  ti  compUcrfenJ  lime  or  it  run  time. 

X  Software  Canpooenu  Ail,  Qt,  I3J.  p  4J1 
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Figure  I:  Dispatcher  Arbitrating  Operating  System  I/O  Calls 

asynchronous  I/O  was  the  correct  mechanism.  Asynchronous  I/O  would 
not  suspend  the  process;  rather  when  the  VO  could  complete,  our  process 
would  be  signaled  and  could  complete  the  rendezvous  through 
Dispatcher.  Details  o f  this  mechanism  under  Berkeley  UNIX  are  left  to 
the  design  section.  Figure  2  shows  the  basic  Interface  between 
Dispatcher  and  the  UNIX  kernel. 

Under.  DEC'S  VMS  operating  system,  the  same  choice  of  asyn¬ 
chronous  VO  would  be  selected.  However,  implementing  that  choice 


would  differ  considerably.  VMS  uses  a  mechanism  called  Asynchronous 
System  Traps  (AST).  The  VMS  mechanism  will  call  a  specified  subrou¬ 
tine  when  an  operation  using  ASTs  hfc>  completed.  Under  Ada,  the 
mechanism  provides  a  task  entry  when  the  operation  has  completed. 
Thus,  the  monitor  task  would  be  implemented  significantly  differently 
under  VMS. 

The  point  is  that  while  the  internals  of  Dispatcher  would  change 
from  operating  system  to  operating  system,  the  programmer-level  syntac¬ 
tic  v  J  semantic  construct  of  the  read,  write,  and  other  calls  would  be 
consistent.  That  is,  while  the  operating  system  dependent  portions  of  the 
code  would  in  fact  change,  the  programmers  would  not  have  to  relearn  a 
new  interface  for  each  new  operating  system. 

This  leads  us  into  another  area  of  our  approach:  maintainability. 
Operating  system  dependent  code  is  an  anathema  to  Ada  thought.  How 
could  we  properly  encapsulate  and  justify  its  use  in  project-oriented  Ada 
development  environments? 


Our  approach  to  this  issue  was  to  observe  that  implementation  of 
an  Ada  program  on  a  particular  platform  under  a  particular  general- 
purpose  operating  system  assumed  a  priori  the  existence  of  personnel 
with  some  expertise  in  that  platform  and  operating  system.  For  conveni¬ 
ence,  we  refer  to  those  people  as  "Gurus."  One  traditional  problem  with 
depending  on  Gums,  at  least  in  our  organisation,  is  that  they  lend  to  be 
available  (albeit  heavily  loaded)  at  the  beginning  of  a  program,  but  are 
reassigned  to  other  programs  later  in  the  life  cycle.  Since  Gurus  partici¬ 
pate  in  the  early  development  activity,  we  have  defined  a  specific  role  for 
them. 

It  Is  a  great  advantage  for  non-Otmi  programmers,  whom  we  call 
"Gentle  Good  People,"  to  work  with  consistent,  operating  system 
Independent  interfaces.  Gentle  Good  People  can  both  program  and  main¬ 
tain  these  interfaces.  This  makes  the  job  of  the  Gurus  the  design  (with 
the  system  and  software  designers)  and  implementation  of  the  operating 
system  dependent  pans  to  provide  the  proper  interface  to  the  Gentle 
Good  People.  Gurus  win  help  design  and  implement  packages  like 
SoeletJO,  while  Gentle  Good  People  should  find  them  easy  and  intui¬ 
tive  to  program  and  maintain. 

Wearing  our  designer's  hat  in  our  choice  of  Intuitive  interfaces,  we 
selected  the  Sequential  JO  package  as  the  best  match  to  what  we  wanted 
from  our  SoeletJO  package.  Any  programmer  who  has  used 
Sequential  JO  should  find  the  SoeletJO  package  very  familiar. 

The  operating  system  dependent  pans  of  the  code  should  be  the 
most  stable  pans  of  the  code,  since  Gentle  Good  People  arc  not  permitted 
to  program  that  interface.  Should  operating  system  revision,  or  perfor¬ 
mance  considerations  require  changes  to  that  code,  a  Guru  should  be 
called  in  to  perform  that  maintenance. 

Wc  feel  that  in  this  way  the  Ada  paradigm  is  best  preserved  while 
recognising  the  inevitability  of  operating  system  dependent  code. 

4.  Design 

Standard  Ada  principles  were  used  in  designing  four  intends  ted 
packages.  For  convenience,  an  overview  will  be  provided  first.  Second, 
the  system  independent  portions  of  the  design  will  be  presented.  Finally, 
the  system  dependent  portions  of  the  design  will  be  discussed. 

4.1.  Overall  Design 

The  SoeletJO  package  Interface  was  designed  to  duplicate  the 
SequentlaIJO  specification  with  ail  of  the  functions  and  procedures 
either  Implemented  or  stubbed  out  for  future  use.  This  allows  users  of 
SoeletJO  to  design  their  applications  to  use  cither  package.  Software 
created  to  this  design  can  use  cither  network  Interfaces  (sockets)  or 
sequential  files  for  communications  between  processes.  This  in  turn 
allows  the  software  to  be  designed  and  coded  before  the  design  decisions 
of  hardware  allocation  or  application  location,  supporting  the  "software 
first"  advantages  of  software  engineering. 

The  principles  used  in  package  design  were  that  as  much  as  possi¬ 
ble,  package  specifications  were  designed  to  be  system  independent.  This 
required  the  design  to  be  informally  tested  to  several  available  systems. 
Second,  the  bodies  were  classified  as  maintainable  by  Gcnde  Good  Peo¬ 
ple  or  Gurus.  We  tried  to  avoid  bodies  that  were  classified  as  needing 
one  type  of  maintalner  except  for  a  procedure  or  two.  The  package 
bodies  that  were  classified  as  maintainable  by  Gcnde  Good  People  tended 
to  be  mostly  system  independent. 

The  resulting  SoeletJO  utility  consists  of  four  major  packages. 
The  generic  package  SoeletJO  (see  SequentlolJO's  specification  in  the 
ANSI/MIL-STD-1SI5A  Section  14.2.3  for  details  of  the  generic  parame¬ 
ter  and  the  allowed  functions  and  procedures),  the  two  packages  Descrip¬ 
tor  and  Socket  which  are  object  abstractions  used  by  Socket  JO  and  the 
Systemjnterfact  package  which  contains  the  system  dependent  interfaces 
to  the  UNIX  operating  system.  A  high-level  diagram  of  the  package 
interfaces  is  provided  in  Figure  3. 
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•  The  SoeketJO  package  is  the  only  package  directly  accessible  by 
the  diems  of  the  utility.  Both  the  specification  and  body  of  SoeketJO 
are  classified  as  system  independent  and  maintainable  by  Gentle  Coed 
Peer  \ 


Figure  3:  Diagram  of  Package  Design 


The  Descriptor  package  Is  an  abstraction  foe  the  object  class 
descriptor.  This  class  of  objects  Is  represented  by  an  Internal  file  of 
records  with  a  unique  fiic.descriptor  (SockeiJD)  as  the  key  for  access. 
There  are  M  functions  and  procedures  allowed  on  this  class  of  objects. 
The  Descriptor  specification  Is  system  independent;  but  as  llie  informs- 
lion  required  for  proper  use  of  a  descriptor  may  change  front  system  to 
system,  the  body  Is  system  dependent  The  functions  are  accessor  and 
bookkeeping  functions,  so  the  body  is  maintainable  by  Gentle  Good  Peo- 
P»e. 

The  Socket  package  is  an  abstraction  for  die  object  class  socket. 
This  class  of  objects  represents  the  actual  operating  system  sockets  and 
allows  six  operations  to  be  performed  on  sockets.  The  Socket 
specification  is  system  independent;  since  the  body  contains  the 
dispatcher  task,  it  is  highly  system  dependent.  We  used  the  separate 
feature  of  Ada  to  remove  die  code  for  the  Dispatcher  body  from  the 
Socket  body.  The  remainder  of  the  Socket  body  requires  a  very  Ada 
knowledgeable  software  engineer  to  maintain,  but  not  necessarily  a  Guru. 

The  Systemjnterfaee  package  encapsulates  the  system  calls  and 
UNIX  routines  to  provide  maximum  portability  with  the  fewest  number  or 
modules  being  affected.  The  Systemjnterfaee  package  consists  mosdy 
of  PRAGMA  INTERFACE  declarations.  Both  the  specification  and  body 
are  very  system  dependent.  We  cUssified  this  package  as  requiring  a 
Guru,  because  classifying  It  odierwisc  early  on  led  to  programming 
blunders. 


4.1,1.  The  SoeketJO  Package  Design 

The  package  Socket  JO  was  designed  to  convctt  the  user  Interface 
of  SequentlalJO  to  the  monitor  function  of  Socket.  The  SoeketJO 
package  provides  the  FILEJTYPE,  F1LGJ.10DE,  and  necessary  opera¬ 
tions  to  niiow  the  using  package  to  receive  and  transmit  data  to  and  from 
other  processes.  The  package  lias  the  only  knowledge  of  the  users’  c/e- 
ment  type  from  the  generic  specification.  Therefore,  it  provides  die  ini¬ 
tial  conversion  from  the  users'  objects  to  the  buffers  the  system  needs  to 
read  and  write.  It  establishes  die  length  and  type  of  element  type  for  any 
necessary  conversions.  The  specification  for  SoeketJO  is  found  in  lilt¬ 
ing  I . 


lOJJrqtlvui; 

in*  riJ*U>T«Tm  it  pivrtc; 
r*ti**t  SoAcijo  it 

in*  nui^rrm  h  pwaic 

ijt<  rulmooe  h  (is'.nu .  lnoutjtle .  ourjiui); 

funcTun  MOD8  (HU!  i  In  ITUUTTO  ttwn  nULMOOC; 

name  otu;  >  in  imurro  «i»™  string; 

r*aidi  IORM  (ITLE  r  tn  F1LE.TYTO  mm  STRING; 
funuiun  IS.OreN  (tUB  i  In  TUJi_TTrlT  Rton  BOOLEAN: 
funoLvn  CSD.OPJUB  ( HIE  t  In  IUE.TYTO  room  BOOLEAN; 

fmrvJurt  CREATE  (ITLE  l  In  wH  llUi.TYtle 

MODS  lb  ITLR.MODH »  LNOUTJTLE; 

NAME  i  In  STRLNO; 

TORM  <  In  STRLNO  »  “* 

prxeimOnS  (nUl  I  In  our  ITLRjnffft 

MODE  i  In  nUi_MODIL 

name  i  u  strlno: 

TORM  I  In  STRLNO  9  “fc 

procc-lure  CLOSE  (HLE  1  in  on  ITLR.TYPE); 

pnxcJwt  DELETE  (TILE  1  In  on  nLHUTEE)  rauinci  CLOSE; 

pnwJure  RESET  (TILE I  In  our  HLE.TTPT; 

MODE  1  In  nULMODEg 

rnwJurc  RESET  (niE  1  In  out  HLEUTPE); 

r»ac«*«READ  OTUliin  TTUi.TTPE; 

ITEM  t  our  ELEME.NT.TYPE); 

proctJuit  WRITE  fflLEitn  ITLB.TYPE; 

ITEM  1  In  ELEMENT.TYPEJc 

I  exetorion  raumes  lOJjcrvrioniNAMEJRROR; 
US  E_ ERROR  :  ucrpkn  raumu  lO.larrfimi.USE.nRKOR; 
STATOS.ERROR ;  uaptlai  mumri  lOJUtrToonLSTATUS.ERROR; 

!  ucrpiion  raumri  K>Jj«Trl<».i_WODI3_D<ROR: 
DEVtra.EXROR  s  ticqnion  iminti  IO_Eut|«Io«u.DEVICEJRROR; 
IJ-D.tRROR  i  weeption  raumci  IO_Eict|tio«i.ENDJRROR; 
DATA.ERROR  t  ocqxion  rawmci  lO.IjrrT'WDATAJRROR; 
pnvtic 

i)T<  FJI E.TYPE  it  new  DciciifiorJlLE  DESCJUPTOR; 
ml  SocielJO; 


Listing  I;  The  SoeketJO  Package  Specification 


4  J.  System  Independent  Design 

.  w  Sy!*c'",in‘fcl>tn<3cm  ^S"  used  the  object  oriented  approach.  Th 
individual  objects  (file  descriptors,  buffers,  monitors)  were  converted  ini 
packages  and  the  operations  on  those  objects  to  functions  and  procedure! 
This  approach  allows  for  easier  maintainability  by  the  Gentle  Good  Pec 
pic  and  Gums  and  a  cleaner  transition  from  host  system  to  host  system. 

The  following  pans  of  packages  were  classified  as  system  indepen 
dent:  the  specifications  of  Descriptor,  SoeketJO,  and  Socket;  the  bod 
at  SoeketJO;  also,  the  specification  of  the  task  Dispatcher  is  systeri 
independent  with  the  exception  of  one  system  dependent  task  entry  point. 


4 2 2.  The  Socket  Package  Design 

The  Socket  package  provides  the  bridge  between  die  completely 
system  independent  SoeketJO  and  the  very  system  dependent 
Systemjnterfaee  package.  The  Socket  package  hides  the  monitor  task 
Dispatcher  in  its  body.  The  OPEN.  CLOSE.  READ,  and  WRiTE  fune- 
lions  provided  by  Socket  are  close  to  those  of  the  underlying  operating 
system,  rather  than  designed  to  mimic  existing  specification  styles  like 
SoeketJO.  The  specification  of  the  Socket  Package  is  found  in  Listing  2. 
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»kh  t>s«rif<cr. 
pulsjtSrtictii 

fmaVmOnS 

pun*  J  in  STRING) 

warn  Dc.rnrwdTU-.nUSCKtrnW, 

fuwtkn  OOSli 

(kkIo  i  in  Deicrij**  nU'.niSCKtl'TOK) 
nun  DciotfiwJTUyyrj.CXinOtt. 

jwctJwtWTtmi 

(uvltt  lintviDcioipivnU'.DI'SCRinOR. 
Wf  1  Vi  SyikmAWJKtSS; 

Wrjoqiii  i  in  tSmSDOc 

RHAD 

(«*i<t  ihM  DcKiirwt  IlLP.DCSamOKi 

Mf  >  in  SriianADDKIXS: 

Mf.imti)!  i  in  INTtGCKk 

ml  &xlci; 

Listing  2:  The  Socket  Package  Specification 


4.2.1. 1.  The  Dispatcher  Task 

Tlte  monitor  task  Dispatcher  provides  the  process  protection 
required  to  prevent  tlte  Ada  environment's  UNIX  process  from  locking 
up.  This  task  uses  both  the  Socket  and  Descriptor  objects  to  ensure  dial 
there  is  data  available  at  die  socket  before  it  allows  the  socket  read  call 
to  be  Issued.  It  remembers  how  many  requests  for  reads/writes  have 
been  processed  and  which  sockets  have  outstanding  read  requests  and 
which  do  not 

The  Ditjxitcher  task  is  buried  in  die  Ixxly  of  Socket  to  completely 
hide  its  existence  from  die  casual  programmer.  The  details  of 
Dispatcher  am  deferred  until  die  system  dependent  design  sections. 

43.  System  Dependent  Design 

System  dependent  design  Is  divided  into  Issues.  The  issues  were 
the  naming  scheme  for  network  addresses,  handling  of  "sockets,"  which 
are  the  underlying  Berkeley  networking  mechanism,  compiler  dependen¬ 
cies.  and  die  resulting  design  of  die  system  dependent  pan. 

The  following  parts  of  packages  were  classified  as  system  depen¬ 
dent:  the  bodies  of  Socket,  Descriptor,  and  Dispatcher.  The  specification 
of  Dispatcher  lias  one  system  dependent  feature,  namely  die  system- 
interrupt  task  entry  name. 

43.1.  Network  Addressing  under  Berkeley 

Berkeley  uses  sockets  to  do  networking.  A  socket  is  an  analogy 
taken  from  the  telephone  company's  old-style  operator  interface.  Clients 
"plug  in"  their  open  request  into  an  awaiting  server  "receptacle."  Tlte 
networking  protocols  built  into  the  UNIX  kernel  are  Internetwork 
Protocol/Transmission  Control  Protocol  (IP/TCP),  developed  under  die 
Defense  Advanced  Research  Brokets  Agency  (DARPA).  IP  provides  net¬ 
work  and  transport  layers,  and  TCP  and  die  Universal  Datagram  Protocol 
(UDP)  provide  session  bye?;  (TCP  Is  a  stream-based  protocol,  UDP  is 
datagram  based).  A  network  address  consists  of  dtree  pans  over  the  IP 
networks.  The  first  pan  is  die  IP  address  of  the  host.  Lookup  routines 
arc  provided  to  determine  an  IP  address  based  on  host  name.  An  IP 
address  has  the  form  of  four  bytes.  As  commonly  represented,  the  bytes 
are  written  as  decimal  integers  separated  by  periods.  The  second  pan  of 
an  address  is  the  protocol  (normally  die  session  bycr  protocol).  The  pro¬ 
tocol  (e.g.,  TCP.  UDP)  is  represented  as  a  small  integer.  Again,  library 
routines  arc  provided  to  translate  a  protocol  name  Into  this  integer.  Tlte 
third  pan  of  an  address  is  the  socket  number  to  perform  the  connection 
on.  Sockets  are  also  represented  by  small  integers.  Since  sockets 
represent  services,  1024  socket  numbers  are  reserved  for  standard  service 
requests,  and  can  only  be  allocated  by  privileged  processes  (i.c„ 
superuser  processes  under  UNIX).  The  system  library  provides  service 
name  lookup  routines  that  convert  the  name  into  die  socket  number. 

An  address  comprises  three  pans;  each  of  the  dtree  parts  can  be  an 
integer  or  a  string.  How  can  we  properly  interface  to  such  a  scheme  in 
Ada? 


Our  answer  was  to  build  a  single  portable  character  suing  provid¬ 
ing  all  the  necessary  Information.  The  suing  has  three  pans,  each  pan 
separated  by  a  colon.  For  each  pan,  the  determination  of  whether  the 
pan  was  represented  by  name  or  number  was  done  by  examining  the  first 
character  in  that  part  of  die  string.  If  die  character  was  a  digit,  the  field 
was  parsed  as  a  number,  otherwise  as  a  name,  in  addition,  if  no  suing 
was  provi  '  for  the  protocol,  a  default  protocol  was  selected  by  die 
UNIX  system.  Some  valid  addresses  follow  in  Table  I. 


Address  string 

Meaning 

atlas: 2000: 

6LI6.1.23:tclnct:tcp 

pluto:3IOO:udp 

Host  atlas  with  socket  2000  and  de¬ 
fault  protocol. 

Host  with  IP  address  64.16.1.23  with 
Telnet  protocol  under  TCP 

Host  pluio  with  socket  3100  and  UDP 
protocol 

Table  1:  Sample  Addresses  for  die  SoekctJO  Facility 


433.  Socket  Communications  Techniques  Under  Berkeley  UNIX 

After  setting  up  an  initial  connection  for  a  socket,  standard  operat¬ 
ing  system  read  and  tvr/r<  calls  will  work  over  the  socket  very  similarly 
to  a  file.  The  main  difference  is  dial  while  file  access  is  fast,  network 
access  can  be  slow.  Therefore  any  read  call  may  return  fewer  characters 
titan  anticipated,  because  of  a  ume  constraint  on  the  sending  side. 

433.  Compiler  Issues 

The  Verdix  Ada  compiler  docs  time-sliced  tasking.  To  do  dtis 
under  Berkeley  UNIX,  it  must  use  operating  system  signals  to  know  dial  a 
timer  lias  expired.  The  UNIX  system  delivers  a  software  interrupt  called 
SIGALKM  to  signal  timer  expiration.  As  stated  In  die  problem  section, 
this  signal  will  interrupt  any  pending  sy  stem  opcrau’ons  dial  can  be  irster- 
nipted  (such  as  a  read  call).  What  is  needed  Is  a  preemption  control 
mechanism  to  prevent  the  Verdix  Ada  run-time  kernel  from  interrupting  a 
system  call.  The  Ada  Rea!  Time  Environment  Working  Croup 
(ARTCWG)  had  already  understood  tills  necessity  and  has  issued  a  sug¬ 
gested  implementation  of  a  preemption  control  package  for  real  time  sys¬ 
tems.  Wc  used  this  same  interface  under  a  general  purpose  operating 
system  widt  the  modified  semande  notion  thit  preventing  preemption 
means  within  this  operating  system  process.  The  preempdon  control  con¬ 
cept  is  similar  to  the  monitor  in  dial  both  mechanisms  aid  in  protecting 
the  operating  system  process  resource. 

43.4.  The  Socket  Package  Body  Design 

The  package  Socket  was  designed  to  xl  as  die  natural  bridge 
between  the  system  independent  SocketJO  and  the  highly  system  depen¬ 
dent  Systemjnterfaee  packages.  This  allows  the  monitor  task 
Dispatcher  to  be  hidden  from  the  user  and  protects  the  system  dependen¬ 
cies  from  die  Gentle  Good  People.  The  Dispatcher  task  divides  the 
SocketMead  request  into  two  pans.  Hie  first  pan  registers  die  caller's 
Inicnt  to  read,  through  the  START_READ  entry;  the  second  pan  rendez¬ 
vous  with  Dispatcher  through  die  STOP_READ  entry,  remaining  blocked 
until  the  read  has  completed  (or  raised  an  exception). 

The  Dispatcher  task  receives  all  UNIX  VO  signals  as  a  task  enuy, 
thanks  to  die  compiler  implementau'on  (most  compilers  examined  support 
this  feature).  Tlte  specification  of  the  Dispatcher  task  is  described  in 
Listing  3. 

w  ah  System; 

*Uh  Descriptor, 

usk  Dispatcher  is 

enuy  Sun_RciJ  (file :  in  Descriptor .FILE .DESCRIPTOR); 

entry StooJUid  (Dcscri^or.HULDnSCHinOR’CO) „ 

DescriptorJUE.DESCWKrOR(3l)  >. 

enuy  S1GIO; 

for  S1GIO  use  >l  System-ADDRESS’REF  (23)  5 

end  Dispatcher; 


Listing  3:  Task  Dispatcher  Specification 
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Hie  UNIX  select  tail  Is  used  lo  determine  which  file*  now  have  I/O 
available.  When  Dispatcher  his  received  enough  input  to  fulfill  a 
SodtaJtcoJ  request  by  a  taller,  the  rendezvous  Is  accepted,  and  the 
caller  can  proceed.  Note  that  the  caller's  semantics  arc  exaedy  as  if  I/O 
was  synchronous. 

To  perform  its  function  the  Dispatcher  relies  on  an  array  of 
descriptors,  which  it  accesses  through  the  Descriptor  package.  In  the 
Descriptor  package,  descriptor  records  have  the  following  format; 

type  descriptor.nxord  is  record 
fd  :  file.deseriptor; 
name :  file.string; 
mode :  filc.mcde; 
form ;  file.string; 

buff :  System.ADDRESS  nult.buff; 
ten  : INTEGER:-©; 
fill :  INTEGER  :-fc 
end  record; 

The  file  descriptor  component  fJ  is  the  index  given  to  a  file  or  socket  by 
the  system  when  opened.  The  component  name  is  the  operating  system 
description  of  the  file;  the  naming  convention  is  described  under  system 
dependent  design.  The  mode  component  has  the  value  IN.E1LE, 
OUT.PILE,  IN.OUTT1LE,  or  closed  (the  dosed  mode  is  available  only 
for  Internal  use).  Thc/orm  component  is  not  In  used  at  tiiis  time,  but  is 
preserved  for  compatibility  with  SequenthlJO.  The  buff  component  is 
used  when  reading  from  or  writing  to  a  socket.  It  holds  die  system 
address  of  the  user-supplied  buffer.  The  integer  ten  represents  die  length 
in  bytes  of  die  user-supplied  h  j/cr.  The  len  component  is  determined 
from  Element  Jype' site  for  whatever  Element J^te  die  user  lias  Instan¬ 
tiated  the  package  with.  The  fill  component  maintains  the  current 
number  of  bytes  read  or  written.  When  fill  reaches  len,  die  read  or  write 
i$  complete,  and  wc  can  rendezvous  with  the  eallLg  procedure. 

The  Dispatcher  task  use*  die  entries  START.READ  and 
STOP.READ  to  synchronize  the  interface  widi  the  users.  The  first  entry, 
START.READ,  notifies  die  Dispatcher  that  a  read  has  been  requested  on 
a  socket.  This  entry  contains  a  parameter  to  indicate  which  socket  (fiJ)  Is 
to  bo  read. 

The  STOP.READ  entry  is  actually  a  family  of  entries  Indexed  by 
the  file.deseriptor.  This  convention  is  used  to  respond  to  one  request's 
completion  without  regard  to  odier  outstanding  requests  dial  may  or  nay 
not  by  In  die  process  of  being  read.  This  allows  dispatcher  to  accept  die 
rendezvous  widi  a  read  request  as  soon  as  it  is  completed. 

The  third  entry,  SIGIO.  Is  used  by  the  system  to  notify  the 
Dispatcher  that  I/O  Is  available. 

Certain  details  must  be  attended  to  make  diis  scheme  be  viable. 
The  UNIX  select  call  must  be  used  two  times  odier  dtan  when  the  I/O 
signal  Is  raised.  First,  when  an  I/O  signal  has  just  been  handled,  files 
must  be  cheeked,  as  rapid  receipt  of  several  I/O  signals  on  several  files 
may  cause  some  signals  to  bo  dropped.  Second,  whenever  we  have  just 
registered  intent  to  read,  wc  check  whedter  I/O  is  possible  since  we  will 
never  respond  to  an  I/O  signal  on  a  file  without  intent  registered. 

While  using  the  I/O  signal  increases  the  number  of  system  calls 
required,  it  has  the  desired  effect  of  eliminating  polling  and  allowing 
remaining  Ada  tasks  to  run  unmolested  while  I/O  is  not  possible. 

Currendy,  die  uritc,  and  open  user-level  calls  are  not  implemented 
asynchronously.  In  the  case  of  write,  asynehronism  is  probably  not 
required.  In  the  case  of  open,  however,  a  process  may  pause  for  up  to 
30  seconds  while  awaiting  connection  (if  the  requested  host  is  unavail¬ 
able).  While  wc  have  not  implemented  it  yet.  an  asynchronous  connect 
is  possible  in  UNIX,  using  the  select  call. 


J.  Results 

One  measure  of  results  Is  the  ease  of  using  the  SoclelJO  utility, 
A  fragment  of  user-level  code  is  provided  in  Listing  4. 


»«lt  Tell  JO; 

*Mi  Sod  <1  JO; 

pwedwt  SotlnJO.UKf  U 

moU  citiiUN  mint  « '«’%  IMS,  *1*  *gV. 

m*  MY.STKISO  U  ««  SDttSO  (I .  Uk 
r*A*S*  MyJO  line  So.to.tO  (MYjroUSOk 

nu:  i  M».io,nLR.Tvrf, 

MODS  1  My.tOJlUi.MOOB  ■  My  JO  INJIU. 

NAMB  <  tuiM  STRING  •  ’.ihciMF. 

FORM  i  or»u*  STXINO  *  **» 
ncM  i  stv.snuNO; 

-  -  OiMl  UttUniiwi 
htw 

m  .  OSes  tnk 

My.IO.Orci>  (nui ,  StOOIS ,  NAMH .  fORM* 

«  _  OSrt  coJ« 

MyjojtM4(nui.nr.Mk 
Tui.tatv.LlM  emUNGOUMft 

H  Ol)ki  (uJi 

Mrjaa**oiu* 

ctcrpian 

M/JOmTVSJXXOR  *> 

TtujO.rw.Unc  CSTATUSJJ<XOH  r»i«4  S*Act  JO** 

«  x  Wxf  atTfii«il 
tivi  SodrtJO.UKr. 


Listing  4;  User-Level  Code  with  the  SockctJO  Utility 

Another  measure  of  results  Is  development  time.  The  SodetJO 
concept  was  developed  in  about  two  person-hours  by  one  language  Guru 
and  one  Ada  Gum.  The  Initial  prototype  took  four  person-weeks,  two  by 
a  Gum -and  two  by  Gende  Good  People.  After  Initial  prototyping,  die 
final  Interface  and  design  required  one  more  person-week,  mostly  used  by 
the  Gum.  The  final  bodies  were  filled  In  In  four  more  person-weeks, 
almost  all  of  that  time  allocated  to  Gende  Good  People.  In  summary,  die 
utility  was  developed  In  ten  person-weeks,  widi  three  person-weeks  alio 
catcd  to  Gurus  and  seven  person-weeks  allocated  to  Gende  Good  People. 

Anodier  measure  of  results  is  efficiency  of  die  final  code  An  Ada 
procedure  was  built  dial  started  five  tasks,  each  of  winch  made  a  connec¬ 
tion  to  a  server.  The  UNIX  shell  (Ibln/csh)  dmc  command  was  used  to 
determine  user  and  system  lime  to  measure  resource  utilization  by  die 
Ada  program.  Two  C  programs  were  written  for  comparison  and  timed 
the  same  way.  The  first  C  program  used  die  UNIX  signal  utility  (much 
like  the  Ada  program),  and  the  second  used  blocking  I/D  calls  to  perform 
the  same  job  as  the  Ada  program.  Tlic  results  are  summarized  in  Table 
2.  In  this  table,  user  time  is  the  amount  of  lime  spent  running  in  die  user 
process  space;  system  lime  is  die  amount  of  time  spent  running  in  die 
operating  system  kernel  space  on  the  user's  behalf.  However; 

•  Tt>e  amounts  measured  are  small  enough,  and  die  variance  large 
enough  to  consider  the  sample  results  equivalent. 

•  A  qualitative  judgement  by  observers  of  die  tests  noted  that  die  C 
programs  seemed  to  provide  results  immediately  on  delivery.  The 
Ada  program  seemed  to  lag  message  delivery  by  a  fraction  of  a 
second. 

•  Tlic  results  are  for  a  particular  version  of  a  particular  compiler,  and 
do  not  reflect  the  capabilities  of  Ada. 
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Test 

Average  User 
Time 

Average  System 
Time 

Ada  Same 

0.00 

030 

Ada  Remote 

0.05 

030 

C  Signal  Same 

0.00 

O.-tO 

C  Signal  Remote 

0.00 

0.45 

C  Blocking  Same 

0.00 

030 

C  Blocking  Remote 

0.00 

040 

Table  2:  Results  of  Tests  of  Adi  versus  C  code  foe  Network  Access 


i.  Current  and  Future  Directions 

Since  the  initial  utility  has  been  completed,  we  are  looking  foe 
ways  to  Improve  the  S<xUtJO  utility  to  be  usable  by  a  larger  number  of 
programs.  The  extensions  being  examined  arc; 

•  Testing  and  Implementing  server -capable  cede.  The  correct  inter¬ 
face  for  a  server  task  under  Berkeley  is  a  good  match  for  the 
Crtatc  procedure  of  SajuinilalJO  (and  thus  SctUtJO  ) 

•  Implementing  the  same  utility  under  DEC'S  VMS  operating  system 
and  Ada  compiler.  TCI', IP  (Wollongong)  and  DECNET  interfaces 
will  be  considered. 

•  Porting  the  same  utility  to  the  Alsys  Ada  compiler. 

•  Understanding  the  issues  involved  with  line-oriented  Interfaces  for 
clients  and  servers  under  Ada,  A  Telnet  diem  Is  perceived  as  a 
good  lest  example. 

7.  Summary 

We  found  the  need  to  follow  several  guidelines  in  writing  Ada 
code  for  operating  system  dependent  features: 

•  Due  the  programming  paradigm  on  existing  packages  or  standards. 

•  Make  sure  that  Gentle  Good  People  find  the  package  Interfaces 
intuitive,  therefore  easy  to  program  and  maintain, 

•  Consider  operating  system  dependent  portions  of  a  design  as  criti¬ 
cal  lower-level  computer  system  components  (CLLCSC),  and  begin 
work  on  them  early. 

•  Make  the  best  use.  of  Gums  that  are  available  mostly  at  the  from 
end  of  a  project,  by  Identifying  the  operating  system  dependent 
portions  of  the  design  and  encapsulating  their  details  in  packages. 
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ABSTRACT 


This  paper  describes  an  experiment  in  the  de¬ 
velopment  of  software  for  a  real-time  system  amt 
graphics  simulator,  written  in  Ada.  Specification  of  the 
problem  was  accomplished  using  the  llatlcy/Pirbhai 
(U/P)  method.  *')  The  program  was  developed  for  use 
on  Sun  Workstations*,  and  the  graphics  simulator 
takes  advantage  of  SunCorc™  package  of  I/O  primi¬ 
tives  and  interactive  graphics.*1*  The  experiment  was 
conducted  at  the  Center  for  Software  Engineering,  Fort 
Monmouth,  NJ.  to  be  used  as  a  future  test  bed  for  soft¬ 
ware  development  methodologies. 


Lo.imQLmiQa 

‘The  objectives  of  this  experiment  were  to  gain 
software  engineering  experience,  use  the  Hat- 
ley/Pirbhai  (li/P)  methodology  to  specify  a  real-time 
software  system,  develop  the  system,  and  build  a 
graphics  simulator  to  represent  an  operational  view  of 
the  system.  Furthermore,  a  system  had  to  be  chosen 
that  could  be  implemented  in  approximately  six  months 
time,  demonstrate  real-time  behavior,  incorporate  a 
non-automated  1 1/P  approach,  and  graphically  repre¬ 
sent  a  system  familiar  to  most  people.  With  the 
above  constraints,  a  multi-elevator  controller  and 
scheduler  was  selected  for  the  experiment.  Elevator 
scheduling  was  a  problem  presented  at  the  1986  ACM- 
sponsored  workshop,  on  software  development  meth¬ 
odologies.  Follow-up  work  was  performed  by  Craw¬ 
ford  l1*,  using  the  PAMELA  (Process  Abstraction 
Method  for  Embedded  Large  Applications)  ™*4*  meth¬ 
odology  and  automated  tool. 


SunWorkstation  is  a  registered  trademark  of  Sun  Mi¬ 
crosystems,  Inc. 

SunCore  is  a  trademark  of  Sun  Microsystems,  Inc. ) 
PAMELA  is  a  trademark  of  George  W.  Cherry 


2,0  DEVELOPMENT  BACKGROUND 

The  four  members  of  the  development  team 
were  interns  in  the  Army  Materiel  Command's,  Soft¬ 
ware  Engineering  program.  The  program  consists  of 
one  year  of  training  a;  the  School  of  Engineering  and 
Logistics,  Texarkana,  TX,  and  a  second  year  of  training 
at  the  Center  for  Software  Engineering,  Fon  Mon¬ 
mouth,  NJ.  This  experiment  was  performed  during  the 
second  year  of  the  Software  Engineering  program. 
Members  of  the  group  had  previously  not  been  it, 
votved  in  the  development  of  a  real-time  Ada  software 
system,  nor  had  they  worked  together  as  a  group. 

3-0  SYSTEM  OVERVIEW 

Elevators  contained  in  the  simulation  have 
many  real  world  features.  Some  or  these  include  sum¬ 
mons  buttons  (up  and  down)  on  floors,  destination  but¬ 
tons  in  elevators,  direction  and  location  lights  on  eleva¬ 
tors,  and  elevator  approach  lights  above  elevators. 
Figure  1  illustrates  the  view  seen  during  the  elevator 
simulation.  Not  shown  in  this  figure,  but  appearing  dy¬ 
namically  during  the  simulation,  arc  doors  opening  and 
closing,  buttons/switchcs  shading  and  clearing,  and 
movement  of  people  (passengers)  in  and  out  of  eleva¬ 
tors.  During  the  simulation,  people  will  enter  elevators 
from  the  left  side,  and  exit  elevators  from  the  right. 

Additional  features  were  added  to  simulate  a 
real  elevator.  Such  features  included  a  nm/stop  emer¬ 
gency  switch,  an  alarm  button,  an  opcn/closc  door  but¬ 
ton,  and  a  power  on/off  switch  (for  maintenance  purpos¬ 
es).  The  nin/stop  emergency  switch  would  stop  the 
elevator  in  between  floors  and  sound  an  alarm,  if 
switched  to  the  stop  position  while  traveling.  Other¬ 
wise,  if  it  is  switched  to  the  stop  position,  while 
stopped  at  a  floor,  it  would  open  the  doors,  keep  them 
open,  and  sound  an  alarm.  The  open  button  stops  the 
elevator  door  from  closing.  It,  however,  has  no  effect 
when  the  elevator  is  in  motion,  or  if  the  door  is  already 
opened.  The  close  door  button  closes  elevator  doors 


7th  Annual  National  Conference  on  Ada  Technology  1389  251 


1JHMJ 

mo*) 

V  1  1  1  1  LiJJ  A 

7  rrnrrmA 

7  ITTTTTn  A 

□ 

□ 

_ 

□ 

□ 

Ll 

□ 

_ 

L 

3 

z 

1 

s 

: 

r 

1 

c 

• 

j 

c 

1 

c 

1 

3C 

pc 

_ 

3C 

pc 

_ 

sc 

pc 

i 

ooooooo 

41m  «!mm  rv*l 

800  oH 

r—f  wo*  rUx 

1114  1  (1 

OOOOOOO 

*tlm  4**  ** 

800  00 
«t-w  tW 

1114  1  (1 

OOOOOOO 

*U  m  (mw  M. 

0  0  O  O0 

t»t»*  (Ua  tv* 

Figure  I. 


faster  than  normal,  by  cancelling  low  priority  levels  as¬ 
sociated  with  the  close  door  function.  Certain  assump¬ 
tions  were  made  on  the  power  on/off  switch,  since  this 
switch  is  key  operated  on  real  elevators,  and  no  real 
experimentation  could  be  performed.  The  on/off  switch 
was  made  to  override  all  other  buttons  and  switches 
for  the  elevator. 

The  elevator  controller  was  designed  to  reflect 
a  user’s  view  of  elevator  systems.  Components  that 
are  not  seen  by  elevator  passengers  (ic.,  floor  sensors 
indicating  an  approaching  elevator)  were  not  incorpo¬ 
rated  into  the  elevator  controller  program.  The  graph¬ 
ics  simulator  is  a  stand-alone  program,  originally  writ¬ 
ten  in  the  C  language,  then  converted  to  Ada  (with  the 
exception  of  the  SunCorc  dependent  portions  of  C 
code).  The  elevator  controller  program  is  interfaced  to 
the  graphics  simulator  program,  to  form  the  complete 
elevator  simulation  system. 

4.0  HATI.KY/PIRBUA1  METHOD 

The  11/P  method  is  an  extension  of  DeMarco’s 
Structured  Analysis  (SA).  The  method  extends 
SA  to  consider  control  flow,  state  machine  behavior, 
and  liming  considerations  in  the  requirements  specifi¬ 
cation  phase  of  development.  Along  with  Data  Flow 
Diagrams  (DFD’s),  Mini-Spccs(callcd  PSPECS  in 
H/P  notation),  and  Data  Dictionary  (DD),  comes  Con¬ 
trol  Flow  Diagrams  (CFD's),  Control  Specifications 


(CSPECS),  and  Timing  Specifications.  CFD’s  map 
control  flow,  just  as  DFD's  map  data  flow.  In  addition, 
CDF's  include  a  symbol  (a  slanted  line)  indicating  an 
interface  with  a  CSPOC  CSPECS  specify  the  finite 
state  machine  behavior  of  the  system.  This  behavior 
can  be  represented  as  a  state  diagram,  process  activa¬ 
tion  table,  or  matrix.  CSPECS  model  real-time  sys¬ 
tem  activity,  according  to  the  H/P  specification  meth¬ 
od.  Timing  Specifications  arc  the  allowable  response 
time  for  the  system  to  respond  to  a  system  input.  Tim¬ 
ing  Specifications  were  not  included  in  this  simulation, 
except  that  the  system  had  to  respond  to  the  user 
within  a  reasonable  time  limit.  The  1  I/P  method  con¬ 
sists  of  two  models,  a  Requirements  Model  (RM),  cur¬ 
rently  being  discussed,  and  an  Architecture  Mode! 
(AM),  which  states  the  system’s  design  structure. 
The  development  group  did  not  construct  an  AM.  It 
was  felt  that  enough  understanding  of  the  system  was 
obtained  by  the  RM,  in  this  ease.  For  a  larger,  or 
more  complex  system,  a  AM  may  have  been  necessary. 

M  SYSTEM.  DESIGN 

Using  the  H/P  method,  the  elevator  design  was 
broken  into  three  sections:  Event  Generator,  for  the  ar¬ 
rival  of  people,  Elevator  Controller,  to  schedule  eleva¬ 
tor  operations,  and  Graphics  Simulator,  to  simulate  the 
functions  of  the  elevator.  Figures  2  and  3  are  illustra¬ 
tions  of  the  Control  Context  Diagram  (CCD)  and  level 
0  DFD/CFD,  respectively,  for  the  elevator  simulation 
system.  DFD’s  and  CFD’s  arc  usually  separated,  but 


Figure  2. 
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were  joined  here,  requiring  less  space. 

In  the  CCD  (Figure  2),  die  system  is  indicated 
by  a  circle,  and  the  external  entities  the  system  com¬ 
municates  with  arc  indicated  by  rectangles.  Data  flow 
is  represented  by  solid  lines,  and  control  flow  by 
dashed  lines.  In  this  case,  the  mouse  was  considered 
pan  of  the  Random  Generator,  and  sends  control  sig¬ 
nals  to  the  elevator  controller.  The  level  0  DFD/CFD 
(Figure  3),  displays  the  three  main  functions  of  the  ele¬ 
vator  system.  The  slanted  bar  in  the  figure  is  the  in¬ 
terface  to  a  CSPEC,  which  will  be  described  later, 

5.1  EVENT  GENERATOR 

The  Event  Generator  accounts  for  the  arrival  of 
people,  and  their  sendee  requests.  This  can  happen  by 
a  random  arrival  generator,  or  by  serial  mouse  input. 
The  random  arrival  generator  contains  four  sub-func¬ 
tions:  an  arrival  generator,  a  starting  floor  generator,  a 
destination  floor  generator,  and  a  processing  function. 
Throughout  the  execution  of  the  simulation,  die  pro¬ 
gram  checks  to  see  if  a  summons  was  generated. 
When  a  summons  is  generated,  a  starting  floor  and  a 
destination  floor  is  then  generated.  If  the  destination 
floor  is  greater  than  the  starting  floor,  an  up  C;ll  is  pro¬ 
duced.  If  the  opposite  is  true,  a  down  call  is  produced, 
if  both  starting  and  destination  floors  arc  equal,  then 
there  is  no  arrival.  The  random  generator  is  designed 
to  avoid  inconsistencies,  such  as  a  passenger  pressing 


an  up  button,  then  pressing  a  destination  floor  below 
the  originating  floor.  Finally,  there  is  no  random  in¬ 
puts  to  nm/stop,  opcn/closc,  and  alarm  buttons,  or  to 
the  on/off  switches. 

5.1.1  SF.RIA1,  MOUSE  INPUT 

Mouse  input  allows  considerable  freedom  (n 
choosing  a  scenario  for  elevator  service  requests.  The 
mouse  can  be  positioned  and  clicked  to  select  any  but¬ 
ton,  or  switch,  on  any  elevator.  Once  a  button  is  se¬ 
lected  by  the  mouse,  it  cannot  be  undone.  However, 
switches  can  be  toggled  on  and  off  at  will.  Thus,  the 
controller  should  be  flexible  enough  to  avoid  being 
tricked  by  clever  operators  of  the  simulator.  One  po¬ 
tential  problem  is  that  mere  people  can  wind  up  leaving 
an  elevator  than  had  originally  entered  it.  This  may  oc¬ 
cur  by  clicking  the  mouse  on  more  than  one  destination 
floor  when  elevator  doors  arc  dosed.  Thus,  at  every 
destination  floor,  at  least  one  person  would  be  seen 
leaving  the  elevator. 

5.2  ELEVATOR  CONTROLLER 

The  elevator  controller  is  designed  to  direct  the 
operation  of  elevators.  The  controller  was  fitst  de¬ 
signed  where  each  of  the  three  elevators  performed  its 
entire  task  (arrival  of  passcngcr(s),  movement  of  ele¬ 
vator,  and  departure  of  passcngcr(s)),  one  at  a  time,  in 
a  round  robin  manner.  This  initial  approach  was  used 
for  testing  purposes,  and  was  not  intended  to  reflect  a 
real  world  situation.  Initially,  the  graphics,  and  the 
controller  and  random  generator  were  developed  inde¬ 
pendently,  In  addition,  the  functionality  of  the  control¬ 
ler  and  random  generator  were  rested  separately. 

The  next  major  step  in  the  development  was  to 
incorporate  a  tasking  scheme.  Tire  program  was  de¬ 
signed  to  use  n+1  tasks,  where  n  is  the  number  of  ele¬ 
vators.  Tasks  were  created  dynamically  for  each  ele¬ 
vator  scheduler,  and  the  additional  task  handles 
events,  and  the  initiation  of  the  other  tasks.  Tire  initial 
design  was  revised  to  correct  a  significant  problem. 
The  problem  concerned  a  race  condition  caused  by  mul¬ 
tiple  tasks  competing  for  the  same  resource,  the 
"graphics".  SunCorc  graphics  restricts  applications  to 
one  open  graphic  segment  at  a  lime.  A  monitor  routine 
was  developed  to  prevent  the  application  from  opening 
more  titan  one  segment  at  any  given  time.  This  protec¬ 
tion  scheme  was  used  to  monitor  the  draw  routines,  fill 
routines,  text  routines,  and  for  the  initialize  routine. 
The  state  diagram  representing  the  control  specifica¬ 
tion  for  initialize  and  update  graphics  functions  (the 
thick  black  slanted  line  in  Figure  3)  is  illustrated  in  fig- 
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ure  4.  While  the  simulation  is  running,  the  system  can 
assume  one  of  thirteen  possible  states,  before  looping 
back  to  the  simulation  running  state,  and  continue  to 
loop  in  this  manner  throughout  the  length  of  the  Simula* 
lion.  A  cyclic  executive  model  was  used,  and  tasking 
(actually  multiprogramming)  required  setting  up  time 
slicing.  Tills  was  done  by  customizing  the  package 


Config,  found  in  the  VADS  UNIX  ™  Implementation 
Reference  Manual/4*  The  addition  of  adding  tasking  to 
the  controller  allowed  multiple  doors  to  graphically 
open  and/or  close  simultaneously. 

5.3  GRAPHICS  SIMULATOR 

The  ll/P  method  was  not  originally  applied  in 
the  specification  of  the  graphics  simulator.  An  initial 
effort  was  established  to  test  the  capabilities  of  the 
SunCorc  graphics  package.  Members  of  the  develop¬ 
ment  team  decided  to  spend  several  man  hours  on  the 
development  of  a  prototype  graphics  simulator,  that  ran 
through  a  predetermined  format,  to  test  every  function 
required  by  the  system.  The  graphics  routines  were 
originally  written,  front  the  bottom  up,  in  C,  as  it  was  a 
language  that  supported  a  convenient  interface  to  Sun- 
Core  graphics.  This  was  necessary  because  Ada  docs 
not  have  a  direct  interface  to  SunCorc  graphics. 


UNIX  is  a  trademark  of  AT&T  Bell  Laboratories 


As  the  graphics  simulator  evolved,  two  genera¬ 
tions  of  prototypes  resulted  before  the  top  down  design 
was  completed.  The  first  prototype  was  a  static  de¬ 
sign,  using  three  elevators  and  seven  floors,  while  the 
second  version  was  dynamic,  allowing  the  user  to  se¬ 
lect  one  or  more  elevators,  and  two  or  more  floors. 
Both  versions  of  the  prototype  were  written  in  C.  With 
lessons  learned  from  the  previous  experience,  a  final 
prototype  was  developed  that  was  more  understand¬ 
able,  portable,  maintainable,  and  reusable.  This  later 
version  was  developed  and  implemented  primarily  in 
Ada.  Portability  was  improved  by  limiting  the  number 
of  graphics  routines.  The  future  use  of  a  different 
graphics  package  requires  modifications  to  only  a  few 
routines.  To  improve  maintainability,  functions  to 
change  size  and  shapes  of  graphical  entities  was  de¬ 
scribed  mathematically.  Ibc  graphics  routines  were 
designed  and  developed  to  be  reusable  for  other  sys¬ 
tems  requiring  graphical  simulation. 

One  of  the  problems  encountered  with  the  Sun- 
Core  graphics  package  was  that  it  contained  no  primi¬ 
tives  to  draw  circles.  One  can  easily  write  routines  to 
draw  circles,  bur  filling  a  circle  (to  light  and  unlight  a 
button)  at  a  reasonable  speed  is  a  bit  more  complex. 
The  best  solution  to  the  circle  phenomenon  was  to  use 
a  dodecagon  instead  of  a  circle.  Dodecagons  can  be 
easily  drawn  and  filled  on  the  user's  screen,  and  for  the 
purpose  of  a  small  button,  it  was  a  close  approximation 
to  a  circle. 

Draw,  Fill,  Text,  and  Initialize  procedures  arc 
listed  below,  along  with  parameter  list  variables. 
These  routines  are  rot  portable,  because  they  depend 
on  the  graphics  package  being  used  (ie„  SunCorc). 
Since  a  monochrome  screen  was  used  during  program 
development,  color  options  were  not  implemented. 


PROCF.DURP.  PARAMETER  LIST 

Draw, . line  thickness,  location,  size 

Fill . shade,  location,  size 

Text . integer/string,  location,  size 

Initialize . none 


Graphics  procedures  used  in  the  Graphics  simulator  in¬ 
clude:  Draw  Triangle,  Draw  Rectangle,  Draw  Dodeca¬ 
gon,  Fill  Triangle,  Fill  Rectangle,  Fill  Dodecagon,  Fill 
People,  Integer  to  Text,  String  to  Text,  Initialize,  Clear, 
and  Exit.  Procedure  Initialize  sets  up  all  parameters 
needed  to  draw  on  the  user’s  screen.  Clear  and  Exit 
functions  are  not  used  by  the  simulation,  as  the  pro¬ 
gram  was  designed  to  run  continuously. 
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Special  considerations  were  involved  in  nuking 
the  program  as  generic  as  possible.  According  to  the 
requirements,  three  elevators  and  seven  floors  were 
specified.  However,  the  progrant  was  designed  to  ac¬ 
cept  the  number  of  elevators,  number  of  floors,  and 
starting  locations  of  elevators,  through  user  (mouse 
driven)  or  randomly  generated  input.  The  elevator 
graphical  mode  is  designed  to  display  a  consistent,  uni¬ 
form  graphical  representation  for  any  given  number  of 
elevators  and  floors. 

6.Q  CONCLUSIONS 

The  H/P  method  proved  to  be  a  useful  approach 
for  the  design  group.  Use  of  the  method  resulted  in  a 
top-down,  modular  design,  which  specified  real-time 
system  requirements.  The  ntethod  was  easy  to  follow, 
and  lead  from  one  step  in  the  requirement;  specifica¬ 
tion  process  to  the  nest,  with  no  loss  of  understand- 
ability.  Since  an  automated  tool  to  implement  this 
methodology  was  not  available,  the  group  felt  a  non- 
automated  11/P  method  is  best  suited  to  small  or  medi¬ 
um  size  projects.  This  is  not  an  indication  of  H/P's 
suitability  to  any  particular  size  project,  but  rather  a 
statement  that  large  systems  could  produce  hundreds, 
or  thousands  of  diagrams,  which  would  nuke  the  non- 
automated  H/P  method  less  practical  to  apply. 


standpoint.  In  future  experiments,  the  elevator  design 
is  scheduled  to  undergo  a  major  modification  from  its 
current  user  standpoint,  to  an  actual  elevator  designer 
standpoint  (ic.,  to  reflect  real  world  objects).  The  in¬ 
terface  between  the  elevator  controller  and  graphics 
simulator  is  to  be  changed  so  the  controller  portion  of 
the  program  can  be  removed,  and  inserted  into  an  actu¬ 
al  running  elevator  system.  Additionally,  by  using  the 
existing  graphics  simulator  as  a  test  vehicle,  and  with 
continued  redevelopment  of  the  elevator  controller, 
various  software  methodologies  and  CASE  tools  arc 
expected  to  be  evaluated.  A  version  for  the  IBM  1*0 
and  compatibles  is  currently  under  development,  to 
demonstrate  portability  of  the  system. 
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REre-BKN’CfnS 


The  importance  of  the  use  of  some  formal  de¬ 
sign  approach  is  apparent.  Which  methodology  is  the 
"best"  to  apply  to  a  given  software  project  may  be  im¬ 
possible  to  predict.  What  is  important  is  that  souk  for¬ 
mal  methodology  be  followed  and  used  (modified)  ac¬ 
cording  to  the  needs  of  the  development  team. 

It  is  the  intention  of  the  elevator  project  group 
to  design  and  develop  several  versions  of  the  elevator 
controller  software,  each  by  a  different  software  meth¬ 
odology.  The  controller's  arc  to  be  used,  in  future  ex¬ 
periments,  with  the  existing  graphics  simulator.  In  or¬ 
der  to  help  minimize  some  of  the  problems  associated 
with  interfacing  hardware  and  software,  an  abstract  in¬ 
terface  should  be  included  in  future  designs. 

7.0  FURTHER  INVESTIGATION 

The  elevator  scheduler  simulation  was  not  de¬ 
signed  to  reflect  a  real  world  elevator  system.  There 
was  no  concept  of  a  motor,  nor  were  there  floor  sen¬ 
sors  incorporated  into  the  design.  Actual  movement  of 
elevators  is  determined  by  buttons  lighting  and  unlight¬ 
ing,  and  doors  opening  and  closing.  This  is,  after  all, 
what  an  actual  elevator  user  would  see.  Thus,  the  ele¬ 
vator  simulation  system  was  developed  from  a  user 
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PROCUREMENT  OF  AIR  TRAFFIC  CONTROL  SOFTWARE  IN  Ada 


Andrew  C.  Chuns 

Federal  Aviation  Administration  Technical  Center 
Atlantic  City  International  Airport,  New  Jcraey 


Su— arv 

The  Federal  Aviation  Administration  (FAA)  Advanced 
Automation  System  (AAS)  prime  contractor  hat 
(elected  Ada  at  the  tingle  High  Order  Language  for 
the  AAS.  During  the  Deaign  Competition  Fhaae,  the 
FAA  requested  the  contractor!  to  develop  and  carry 
out  their  Ada  risk  management  plant,  to  complete 
their  toftware  top  level  deaignt  in  a  compilable 
Ada-bated  Program  Deaign  Language,  to  conduct 
incremental  detailed  deaign  walkthrough!,  and 
to  demonttrate  their  Ada  readi.neaa  with  Ada 
compiler  benchmark!,  Ada  Programming  Support 
Environment  (APSE)  tool  demonatratlont,  ar.d 
Software  Engineering  Exercitet.  During  the 
Acquisition  Phate,  the  FAA  implement!  the  AAS  in 
three  trantltion  ttatet  with  different  Ada  ritk 
control  goalt:  State  1,  complete  the  development  of 
ettential  APSE  toolt  and  automate  en  route  Air 
Traffic  Control  (ATC)  operation!  by  introducing 
ttetor  tuitet;  State  2,  modernize  batie  ATC  data 
procetting  equipment  and  automate  tome  terminal  and 
tower  ATC  operationt;  and  State  3,  enhance  ATC 
automation  procetting  capabiliciet  and  automate  the 
remaining  terminal  and  tower  ATC  operation!.  The 
FAA  encourage!  uat  of  Commercially  Available 
Software  to  minimize  development  and  to  facilitate 
future  technology  intertion. 


Introduction 

The  Advanced  Automation  Syttem  (AAS)  being 
developed  at  the  Federal  Aviation  Administration 
(FAA)  will  modernize  the  United  State!  Air  Traffic 
Control  (ATC)  tyttem.  Ada  hat  been  (elected  at  the 
tingle  High  Order  Language  (HOL)  for  the  AAS.  In 
thit  paper  we  will  detcribe  why  Ada  wat  ehoten  and 
how  Ada  ritkt  arc  managed. 

Background 

The  FAA  en  route  air  traffic  controller!  ute  20  Air 
Route  Traffic  Control  Ccntcrt  (ARTCCt)  to  control 
all  en  route  traffic  in  the  continental  United 
States.  At  pretent  etch  ARTCC  has  a  pair  of  IBM 
3083  processors,  one  processor  being  in  operational 
mode,  and  the  other  on  standby.  These  3083 
processors,  called  the  Host  Computer,  were  deployed 
from  late  1986  through  1988  to  replace  the 
previous  en  route  procesior,  IBM  9020.  During  the 
rehosting,  the  en  route  National  Airspace  System 
(NAS)  software  underwent  minimum  changes.  In 
addition  to  the  en  route  facilities,  the  FAA  also 
has  approximately  600  Airport  Traffic  Control 


Towers  (ATCTt)  for  directing  takeoffs  and  landings, 
and  almost  200  Terminal  Radar  Approach  Controls 
(TKACONt)  for  directing  the  movement  of  traffic  at 
and  in  the  vicinity  of  airports.  The  TRAC0N  it 
often  located  one  floor  below  the  ATCT.l 

The  AAS  will  introduce  new  workstations  for  en 
route,  tower,  and  terminal  air  traffic  controllers. 
It  will  also  consolidate  TRACONs  end  ARTCCt  into 
new  Area  Control  Facilities  (ACFt),  which  will  be 
located  at  the  existing  ARTCC  locations.  The  AAS 
will  be  a  distributed  system;  operations  requiring 
centralized  processing  will  be  accomplished  in 
the  centralized  computers,  with  all  remaining 
functions  performed  within  the  individual  sector 
suites.)  A  Local  Communication  Network  (LCN) 
will  perform  all  data  transmission  among  these 
distributed  processors.  Hie  overall  Reliability, 
Maintainability,  and  Availability  (XMa)  design  goal 
of  the  operational  AAS  segments  is  to  continuously 
provide  full  service  operation  throughout  their 
service  life.  Specifically,  the  full  service  mode 
of  the  final  AAS  state  shall  not  break  down  for  a 
period  of  sore  than  2.6  minutes  per  year.  If  a 
system  fault  ever  occurs,  the  ATC  services  shall 
still  be  sustained  or  gracefully  degraded. 
Therefore,  layers  of  fault  tolerance  mechanisms, 
such  as  hardware  redundancy,  on-line  system 
performance  monitoring,  automatic  service  mode 
switching,  and  facility  backup  will  be  employed 
to  maintain  essential  ATC  functions.  Rapid 
isolation  and  replacement  of  faulty  hardware  parts 
and  software  components  are  also  required  to  ensure 
fast  recovery  of  full  ATC  services. 

The  AAS  Design  Competition  Phase  (DCP)  contracts 
were  awarded  to  teams  led  by  Hughes  Aircraft 
Company  and  International  Business  Machines 
Corporation  (IBM)  in  August  1984.  The  DCP  contract 
ended  in  July  1988,  and  the  IBM  team  was  awarded 
the  AAS  Acquisition  Phase  (AP)  contract. 

Selection  Of  Ada 

The  FAA  required  the  AAS  DCP  contractors  to  select 
a  single  HOL  for  developing  AAS  software.  Both 
contractors  produced  a  "Language  Selection  Analysis 
Report"  9  months  after  DCP  contract  award.  This 
report  required  that  the  contractors  first  identify 
all  the  HOL  candidates  which  would  be  suitable 
for  the  AAS  requirements,  then  detail  the 
advantages  and  disadvantages  of  each  according 
to  specific  language  quality  factors,  and 
finally  select  one  language  as  the  HOI  for 
the  AAS. 
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The  HOI  candidates  Included  these  languages:  JOVIAL 
J73,  FORTRAN,  C,  rascal,  and  Ads.  A»U  w**  selected 
over  the  other  HOL*  by  both  contractor*.  The 
rationale  for  their  choice  Included  factor* ,  «uch 
a*  the  better  ccpabllltle*  of  the.  Ad*  language  and 
the  fact  that  Ada  code  l*  considered  the  beat 
In  area*  of  reliability,  maintainability ,  and 
extensibility. 

Heliabillty. 

The  major  Ada  feature*  which  contribute  to  a 
reliable  software  are  strong  typing,  exception 
handling,  and  numeric  precision.  Strong  typing 
help*  maintain  data  integrity.  Exception  handling 
help*  software  fault  detection  and  correction. 
Kuserlc  precision  ensures  that  a  program  can  be 
expected  to  perform  it*  Intended  function  with 
required  precision. 

Maintainability  And  Extensibility. 

The  AAS  ausc  be  maintainable  not  only  to  achieve 
the  high  system  availability  but  also  to  reduce  the 
life  cycle  cost.  The  incremental  evolutionary 
development  of  the  AAS  requires  software 
extensibility.  Packages  and  generic*  are  the 
aajor  Ada  feaeure*  which  contribute  to  Its 
maintainability  and  extensibility. 

Language  Capability. 

The  AAS  software  will  perfora  a  wide  range  of 
function*  including  run-time  system,  information 
display,  computation-intensive  functions,  data 
aanageaent ,  command  and  control,  and  message 
transmission.  Ada  hat  the  potential  to  be  able  to 
do  all  of  these  function*. 

Ada  Risk  Management  In  AAS  DCP 

Having  reviewed  the  Language  Selection  Analysis 
Reports,  the  FAA  was  concerned  about  the  immaturity 
of  Ada  technology  and  requested  each  contractor  to 
develop  Ada  risk  reduction  plan  and  to  report  on 
their  Ada  risk  reduction  activities  monthly.  In 
late  1986,  an  FAA  software  team  conducted  a 
worldwide  Ad*  usage  survey,  while  a  committee 
composed  of  Ada  and  software  engineering  experts 
was  commissioned  by  the  FAA  to  do  an  independent 
study  on  the  use  of  Ada  for  the  AAS. 

Ada  Usage  Survey. 

Alice  Wong,  who  was  the  FAA  AAS  Software  Technical 
Specialty  Team  Leader,  led  the  Ada  usage  survey. 
Hie  purpose  of  the  survey  was  to  gather  information 
on  Ada  software  development  experiences  and  Ada 
risk  management  approaches.  We  interviewed  about 
26  Ada  project  personnel  by  telephone  and  also 
visited  NASA  Johnson  Space  Center  at  Houston,  Texas 
and  toe  Aviation  Croup  of  Transport  Canada  at 
Ottawa,  Canada.  Our  major  findings  were  reported 
to  the  AAS  Program  Director  in  January  1987, 
as  follows: 

Ada  Compiler  And  Its  Performance  Were 
Essential  To  Project  Success.  As  of  November  1986, 
there  ware  only  65  validated  Ada  compilers. 


Performance  of  Ada  compiler*  must  be  evaluated  for 
specific  applications.  Shortage  of  good  Ada 
compilers  had  resulted  in  waiver  request*  by 
•ome  defense  system  implementor*.  Four  projects 
surveyed  had  interim  deliverable*  in  Pascal. 
One  project  used  an  Ada  Program  Design  Language 
(PDL)  for  designing  the  software  but  implemented 
it  in  "C." 

Ada-Based  PDL  Should  »e  Used  For  Software 
Design.  Twenty-three  of  the  26  projects  surveyed 
had  used  or  were  planning  to  use  an  Ada-based  PDL 
because  it  promote*  the  use  of  modern  software 
engineering  principles.  A  project  could  benefit 
from  the  use  of  Ad*  PDL  even  if  the  implementation 
language  is  not  Ada.  Mast  projects  have  customised 
Ad*  PDL  guidelines. 

Major  Ada  Projects  Had  Ada  Programming  Support 
Environment  (APSE)  Tailored  For  Their  Spec  if fc 
Application*. 

1.  The  Ada  Language  System/Kavy  (ALS/N)  would 
provide  program  generation  and  execution  support 
for  mission-critical  sofeware  targeted  to  standard 
Navy  embedded  computer*.  The  primary  focus  was 
run-time  performance. 

2.  The  Worldwide  Military  Command  and  Control 
System  (WWMCCS)  Information  System  (WIS)  had 
Software  Development  and  Maintenance  Environment 
(SOME). 

3.  National  Aeronautics  and  Space 
Administration  (NASA)  Space  Station  Program  (SSP) 
had  a  Request  for  Proposal  (RFP)  for  the  Software 
Support  Environment  (SSE)  in  1986. 

Ada  Training  Was  Crucial  For  Ada  Software 
Development.  Cood  Ada  programmer*  needed  at 
least  6  months  of  training;  2  to  6  week*  of 
basic  training  and  the  remaining  period  spent  in 
on-the-job  training.  Projects  that  had  tried  to 
shortcut  formal  classroom  training  had  paid  for  it 
somewhere  in  the  development  process. 

"Use  Of  Ada  For  AAS"  Study  Results. 

The  "Use  of  Ada  for  AAS"  Study  Committee,  chaired 
by  Dr.  Victor  R.  Basili  of  the  University  of 
Maryland,  recommended  use  of  Ada,  as  well  as  risk 
reduction  activities  for  the  AAS.*  To  implement 
the  committee  recommendations,  the  FAA  requested 
both  DCP  contractors  to: 

1.  Complete  their  software  top  level  designs  for 
the  Initial  Sector  Suite  System  (ISSS)  and  the  ISSS 
System  Support  Computer  Complex  (SSCC-1)  using 
an  Ada-baaed  PDL  which  can  be  compiled  with  a 
validated  Ada  compiler, 

2.  Conduct  incremental  Critical  Design  Review 
(CDR)  software  detailed  design  walkthroughs  for  the 
ISSS  and  SSCC-I,  and 

3.  Demonstrate  their  Ada  readiness  with  Ada 
compiler  benchmarks,  Sofeware  Engineering  Exercises 
and  APSE  demonstrations.? 
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Ad*  Riak  Hanageawnt  In  MS  AP 

Th«  AAS  will  be  * mplemcntdd  In  three  major 
atate*:3'4  (I)  ISSS,  (2)  Tower  Control  Computer 
Complex  (TCCC)  and  Terminal  Advanced  Automation 
Syatem  (TAAS) ,  and  (3)  Area  Control  Coaputcr 
Complex  (ACCC) .  The  AAS  aite  transition  apread* 
over  a  period  of  A  year*  (Auguat  1993,  to 
November  1999).  The  tranaltion  plan  and  the 
tong  teet  and  evaluation  period  of  about  3  year* 
for  each  nut  help  reduce  Ada  riak*.  Leaaona 
learned  in  earlier  atate*  will  benefit  later 
onea. 

Firat  State  -  ISSS. 

The  ISSS  introducer  the  aector  auite  with  diaplay 
and  input  devicea  for  en  route  controllcri.  The 
aector  auite  conaiata  of  one  to  four  coaaon 
controller  workstation*  called  coaaon  console*, 
which  will  be  uaed  for  all  en  route,  terminal,  and 
tower  operationa.  The  current  Hoat  Computer  Syatem 
(HCS)  uaea  Plan  View  Diaplaya  (PVDa)  for  radar 
data  diaplay  and  flight  atrip  printera.  The 
common  conaolea  which  can  diaplay  both  radar 
and  flight  plan  data  will  replace  both  the  PVDa 
and  flight  atrip  printera.  The  current  KAS 
aoftware  in  the  HCS  will  continue  to  perform  ehe 
bulk  of  the  ATC  data  proeeaalng,  and  aend  ehe 
proceaaed  radar  and  flight  plan  data  to  the 
aector  auitca  for  diaplay.  The  emphaaia  of 
thia  atate  ia  the  aector  auite  Computer-Human 
Interface  (CHI). 

The  SSCC-1 ,  Utieh  will  be  delivered  with  the  firat 
ISSS  to  the  FAA  Technical  Center,  will  perform  the 
functiona  of  Syatem  Modification,  Syatem  Teatlng 
and  Verification,  and  Field  Support  for  the  ISSS. 
The  Job  £hop  of  the  SSCC-I  will  contain  the  APSE 
for  developing,  andifying,  and  maintaining  the  AAS 
Ada  aoftware.  The  SSCC-1  alao  haa  a  Facility 
Configuration  Conaole  (FCC),  a  Stand-Alone 
Simulator  (SAS),  an  ISSS  Syatem  Support  Facility 
(SSF),  and  coamon  conaole  aimulatora.  For  ayatem 
tearing,  the  SSCC-1  can  emulate  any  deployed  ISSS 
aite. 

The  Ada  riak  reduction  taaka  for  the  cirat  atate 
are  aa  followa: 

1.  Develop  a  complete  act  of  APSE  toola  applicable 
for  the  AAS,  The  Ada  compiler  muat  be  able  to 
compile  at  leaat  1,000  executable  aource  code 
atatementa  per  minute.  The  compiler  library 
manager  muat  be  able  to  handle  a  large  AAS-like 
aoftware  ayatem  containing  more  than  1  million 
aource  linea  of  code.  The  compiler-generated 
machine  code  and  the  run-time  ayatem  for  the 
common  conaole  proceaaor  mutt  be  aufficient  to  meet 
the  aector  auite  workload,  reaponae  time,  accuracy, 
and  RMA  requirements. 

2.  Street  the  importance  of  factory  teating  of 
Computer  Software  Unita  (CSUt),  Computer  Software 
Componenta  (CSCt),  and  partial  aoftware  buildt. 
The  aoftware  detailed  deaign  for  ISSS  and  SSCC-1 
waa  completed  in  the  DCP. 


3.  Complete  the  ISSS  acceptance  teat  baaed  on 
IS  pre-production  unita  of  the  common  conaole 
before  authorixlng  an  ISSS  limited  production 
relaaae. 

A.  Complete  the  ISSS  Operational  Teat  and 
Evaluation  (OTAE)  baaed  on  the  limited  production 
model  of  the  common  conaole  before  authorixlng  the 
ISSS  full  production  release.  The  total  number  of 
co«*ion  conaolea  to  be  inatalled  in  20  ISSS  altea 
will  be  about  2,S30. 

Second  State  -  TCCC  And  TAAS. 

In  the  accond  atate,  the  TRACON  function  of 
aelected  Automated  Radar  Terminal  Syatam  (ARTS) 
faellitiea  will  be  tranaferred  to  ARTCCs  to  form 
TAASa,  while  aome  of  the  correaponding  ATCTa  will 
receive  TCCCa.  The  TAAS  to  be  collocated  with  the 
ISSS  will  introduce  aector  auitca  to  approach  and 
departure  ATC  operationa.  The  TAAS  will  receive 
flight  data  from  the  HCS  in  the  amae  way  aa  the 
ARTS  111  now  doea.  Central  proceaaora  will  be  uaed 
at  the  TAAS  to  perform  the  baaic  ATC  functiona 
which  include  Surveillance  Data  Procetaing, 
Automatic  Tracking,  Flight  Man  Proeeaalng, 
Separation  Aaaurance,  Weather  Proeeaalng,  Digital 
Bright  Radar  Indicator  Towar  Equipment  (D-SR1TE) 
Support  Proeeaalng,  Ancillary  Proeeaalng,  Interim 
Altitude  Proeeaalng,  and  Sector  Suite  Configuration 
and  Sectorixation. 

The  TCCC  will  introduce  TCCC  Poaition  Conaolea 
(TPCa)  to  the  tower  controllers.  The  TPC  la 
comparable  in  nature  to  the  common  conaole  of  the 
ISSS  and  TAAS.  According  to  the  commonality 
requirement,  both  the  TPC  and  the  common  conaole 
use  identical  proceaaora  and  memory  parti.  Towar 
proceaaora  will  ba  uaed  at  the  TCCC  to  perform  Che 
baaic  ATC  functiona  which  include  Surveillance  Data 
Proeeaalng,  Flight  Plan  Proeeaalng,  Handoff  of 
Controlled  Track*,  Separation  Aaaurance,  Weather 
Proeeaalng,  Airport  Environmental  Data  Proeeaalng, 
ATC  Mail,  and  Traffic  Management. 

The  TCCC  ha*  two  mode*  of  operation;  i.e.,  normal 
mode  and  stand-alone  mode.  In  it*  normal  aade,  the 
TCCC  utilize*  the  aurveillance  aircraft  data 
and  flight  plan  data  obtained  from  the  parent  TAAS 
for  diaplay  at  the  TPC*.  In  Che  atand-alone  mode, 
when  Che  communication*  between  the  TCCC  and  it* 
parent  TAAS  are  unavailable,  the  TCCC  will  perform 
limited  aurveillance  proceeding  and  flight  plan 
proeeaalng. 

In  thia  atate,  Che  SSCC-1  at  the  FAA  Technical 
Center  will  have  been  upgraded  twice,  becoming 
firat  Che  SSCC-2  by  receiving  a  TCCC  SSF,  and  then 
the  SSCC-3  by  receiving  a  TAAS  SSF. 

The  Ada  riak  reduction  taaka  for  the  aecond  atate 
are  a*  followa: 

1.  Perfect  the  code  generation  and  run-time  ayatem 
of  the  Ada  compiler  targeted  to  the  central 
proceaaor,  tower  proceaaor,  and  TPC  proceaaor  to 
meet  Che  workload,  reaponae  time,  accuracy,  and  RMA 
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requirement*  of  the  TAAS  end  TCCC.  the  front  end 
of  the  compiler  i»  the  »«n  4*  that  targeted  to  the 
common  console  processor.  therefore,  the  required 
compilation  speed  end  capacity  of  the  compiler  will 
have  been  achieved  during  the  firm  transition 
state,  the  AAS  A P  priae  contractor  has  proposed  to 
use  a  saaller  modal  of  the  central  processor  for 
the  function  of  Display  Data  Recording  and  Playback 
during  the  1SSS.  Now  the  central  procesaor  will 
also  be  used  for  the  TAAS  basic  AtC  functions.  The 
experiences  in  using  the  central  processor  during 
the  first  state  will  help  reduce  the  risks  in  the 
second  state. 

2.  Conduct  incrcaental  CORa  for  ACCC  and  TCCC  to 
coaplete  their  software  detailed  design  in  Ada  FDl. 
The  ACCC  COR  includes  the  TAAS  COX  as  a  subset. 
Because  of  the  siailarity  of  some  basic  ATC 
functions  of  TCCC  and  TAAS,  reuse  of  their  common 
source  code  is  encouraged. 

3.  Stress  the  iaportauce  of  factory  testing  of 
CSUs,  CSCs  and  partial  software  builds. 

A.  Coaplete  the  FAA  Technical  Center  acceptance 
teat  and  0T4E  of  the  TPC  based  on  2A  units  of  the 
pre-production  aodel  before  authorizing  the 
production  release  of  the  TPC.  The  total  nuober  of 
TPCa  to  be  deployed  ac  2S8  field  TCCCa  chrough  Che 
end  of  che  third  transition  state  is  almost  1,450. 

Third  State  -  ACCC. 

The  ACCC  it  evolved  froa  the  1SSS  sector  suites 
and  TAAS  by  adding  aore  sector  suites  and  ATC 
functions.  The  additional  sector  suites  provide 
Traffic  Management  Poaitiona,  Oceanic  Control 
Positions,  and  Flight  Data  Honitor  Poaitiona.  The 
additional  AtC  functions  are  Autoaation  Processing, 
Oceanic  Processing,  Facility  Bacl'.up,  Search 
and  Rescue  Data  Extraction,  Custom  Trans-Border 
Detection  Alert,  Notice  to  Airmen  Processing,  and 
International  Civil  Aviation  Organization  (ICAO) 
Message  Processing.  The  Autoaation  Processing  is 
the  first  implementation  package  of  Automated  Sn 
Route  Air  Traffic  Control  (AF.RA-1),  which  includes 
Flight  Plan  Conflict  Probe,  Sector  Workload 
Analysis,  Trial  Flight  Plan,  Reconforaanee  Aid, 
and  Reminder  Function.  The  Facility  Backup 
capabilities  allow  adjacent  ACFa  to  manage  che 
airspace  of  an  ACF  that  haa  had  a  catastrophic 
failure.  Additional  approach  and  departure  ATC 
operations  will  be  transferred  from  ARTS  facilities 
to  the  ACCC,  and  che  corresponding  ATCTs  will  be 
equipped  with  TCCCs. 

With  the  delivery  of  the  first  ACCC  to  che  FAA 
Technical  Center,  the  SSCC-3  will  be  upgraded  to 
become  SSCC-A  by  receiving  an  ACCC  SSF.  Also  in 
this  state,  a  Research  and  Development  Computer 
Complex  (RDCC)  will  be  created  to  contain  a  full 


complement  of  ACCC  and  TCCC  capabilities  to  support 
the  testing  of  advanced  ATC  concepts,  hardware 
upgrades,  and  new  software  functions. 

The  Ada  risk  reduction  tasks  for  the  third  state 
are  as  follows: 

1.  Improve,  if  necessary,  the  Ada  compiler 
targeted  to  the  central  processor  to  meet  the 
workload,  reaponac  time,  accuracy,  and  RMA 
requirements  of  the  ACCC. 

2.  St  res'  the  importance  of  factory  testing  of 
CSUs,  CSCs,  and  partial  software  builds. 

The  ACCC  will  have  the  capacity  and  functional 
capability  to  support  fully  integrated  en  route  and 
terminal  approach  and  parture  ATC  operations 
including  future  expansions.  A  planned  future 
expansion  is  the  AEKA-2  which  will  extend  che 
Automation  Processing  of  the  ACCC  to  provide  che 
ATC  controllers  with  Conflict  Resolutions,  Metering 
Actions,  tnd  Automatic  Clearance  Ceneraclon. 

Use  Of  Commercially  Available  Software  (CAS) 

For  Advanced  Automation  System  (AAS)  " 

Sinee  the  FAa  prefers  use  of  standard  commercial 
products  to  minimize  development,  the  AAS  contains 
many  CAS  Items,  such  as  compilers,  losders,  LCN 
software,  operating  systems,  screen  graphic 
generator,  and  data  base  management  system.  The 
use  of  CAS  not  only  reduces  the  amounc  of  Ada 
software  to  be  developed  but  also  facilitates  new 
technology  insertion.  For  example,  use  of  CAS 
operating  system  and  Ada  compiler  allows  us  to 
adopt  their  future  upgraded  versions  more  readily. 
Mott  of  the  AAS  CAS  items  are  not  Ada  software 
because  very  few  standard  Ada  CAS  items  are  now 
available.  However,  when  AAS  software  needs  to  be 
upgraded,  we  could  replace  some  non-Ada  CAS  items 
with  equivalent  Ada  CAS  items,  if  then  available. 

Conclusion 

The  Advanced  Automation  System  (AAS)  contractor  has 
selected  Ada  at  che  single  High  Order  Language 
(IIOL)  to  develop  che  AAS  sofeware.  Sound  aoftware 
engineering  practices  are  emphasized  to  design  che 
Ada  aoftware.  Ada  Programming  Support  Environment 
(APSE)  cool*  have  been  assembled  to  develop, 
test,  and  maintain  Che  Ada  code.  An  AAS  transition 
plan  which  requires  incremental  delivery  of  Ada 
software  in  three  ttacei  helps  reduce  risks.  Use 
of  Commercially  Available  Software  is  encouraged  to 
reduce  new  software  and  to  keep  pace  with  future 
technology  advances.  The  AAS  development  has 
benefited  from  the  Ada  technology  accomplishments 
of  the  past.  Ue  continue  to  depend  on  che  future 
Ads  technology  for  successful  AAS  implementation 
and  maintenance. 
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ABSTRACT 

This  paper  present*  a  concept  for  the  use  of  a 
Software  Engineering  Exercise  (SEE)  during  the 
source  selection  process  of  a  system  acquisition. 
The  development  of  acquisition-specific  SEE 
requirements  are  discussed,  along  with  the 
development  of  criteria  to  evaluate  the  offerors' 
performance  of  a  SEE.  Also  addressed  is  the 
recommended  composition  of  the  evaluation  team  and 
the  overall  evaluation  approach. 

Finally,  this  paper  concludes  that  the  use  of  a  SEE 
may  not  be  appropriate  for  all  source  selections 
but  is  definitely  an  asset  when  used  during  large- 
scale  system  acquisitions. 


1.0  INTRODUCTION 

l.l  Background 

The  Federal  Aviation  Administration  (FAA)  has  begun 
an  extensive  plan  to  both  modernise  and  enhance  the 
current  Air  Traffic  Control  (ATG)  system.  This 
plan,  titled  the  National  ALrspace  System  (NAS) 
Planjl],  is  currently  composed  or  over  ninety 
projects.  The  cornerstone  of  the  NAS  Plan  Is  the 
Advanced  Autosuitlon  System  (AAS).  The  AAS  is 
designed  to  1)  replace  aging  equipment  whose 
capacity  and  availability  cannot  meet  the  ATG  needs 
of  this  decade  and  2)  replace  the  flrst-of-lts-klnd 
software,  which  is  limited  In  extensibility,  to 
meet  the  ATC  functional  and  capacity  needs  through 
the  end  of  the  decade. 

The  development  of  the  AAS  project  Is  broken  down 
Into  two  phases,  the  Design  Competition  Phase  (DCP) 
and  the  Acquisition  Phase  (AP) .  Hie  AP  as 
specified  by  the  FAA  Is  analogous  to  the  Department 
of  Defense's  Fdll-Scale  Development  Phase.  Two 
contractors  were  selected  to  participate  In  the 
DCP.  The  main  goal  of  the  DCP  was  for  each 
contractor  to  develop  Independently  a  design  for 
the  overall  AAS  that  met  all  of  the  requirements 
contained  In  the  FAA's  System  Level 
Specification. (2)  Additionally,  special  emphasis 
was  to  be  placed  on  the  development  of  prototype 
hardware  and  software  for  the  AAS  man-machine 
Interface  (controller  work  station).  At  the 
conclusion  of  the  DCP  both  contractors  provided 
proposals  for  the  actual  development  of  the  AAS 
project  during  the  AP. 


During  the  DCP,  the  FAA  required  that  a  single 
hlgh-ordcr  language  (MOL.)  be  selected  to  implement 
the  overall  system  requirements.  Non-cost 
beneficial  exceptions  to  this  requirement  were  to 
be  granted  on  a  case-by-case  basis  only  when  fully 
Justified  by  the  DCP  contractor  and  approved  by  the 
FAA.  Anticipating  that  the  contractor  selected  to 
Implement  the  AAS  might  choose  the  Ada  language  as 
their  single  HOL  and  citing  Its  lack  of  experience 
with  Ada,  the  FAA  commissioned  a  study  to  address 
the  use  of  Ada  for  the  AAS. (3, A)  As  part  of  this 
study,  risk  areas  were  Identified  and  appropriate 
risk  reduction  activities  were  recommended.  One  of 
the  recommended  risk  reduction  activities  to  be 
conducted  prior  to  the  selection  of  the  AP 
contractor  was  the  conduct  of  a  Software 
Engineering  Exercise  (SEE). 

Since  the  Information  developed  during  the  conduct 
of  the  FAA  SEE  was  part  of  the  source  evaluation, 

It  Is  considered  source  selective  sensitive.  Also, 
the  SEE  as  specified  as  pare  of  the  DCP  was  unique 
to  the  AAS  and  not  reflective  of  the  general 
development  of  a  SEE  as  depicted  In  this  paper. 
Therefore,  this  paper  will  not  cover  the 
Implementation  of  the  FAA-speclflc  SEE  but, 
instead,  will  discuss  SEE  requirements  In  general 
end  the  steps  Involved  In  the  conduct  of  a  SEE. 

For  the  development  of  these  general  requirements, 
background  Information  was  taken  from  the  exercises 
that  have  been  published. [5,6, 7, 8) 

l-Z  SEE-Btscrlptlon 

A  SEE  Is  a  small-scale  system  design  exercise 
conducted  by  each  offeror^  and  evaluated  by  the 
Government  during  proposal  evaluation.  It  Is 
Intended  mainly  to  evaluate  the  offeror's  design 
methodologies  as  documented  In  both  the  Software 
Development  Plan  (SDP)  and  Software  Standards  and 
Procedures  Manual  (SSPH)2  and  demonstrated  through 
the  doslgn  of  the  exercise  system.  It  also  may  be 
used  to  assess  the  offeror's  software  management, 
software  tools,  software  code,  and  software  testing 
techniques.  This  evaluation  process  Is  Intended  to 
allow  the  Government  to  assess  the  degree  of  risk 
associated  with  the  offeror's  software  development 
methodology.  Successful  accomplishment  of  a  SEE  by 

^  The  term  offeror  Is  used  to  refer  to  all 
respondents  to  the  Request  for  Proposal. 

2  When  referring  to  both  the  SDP  and  SSPM  Jointly, 
they  will  be  called  the  "proposed  plans"  throughout 
the  remainder  of  this  paper. 
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«n  offeror  will  give  some  assurance,  although  no 
guarantor ,  that  the  offeror  has  the  ability  to 
coaplete  the  design  phase  successfully.  On  the 
other  hand,  the  failure  of  an  offeror  to 
successfully  complete  a  SEE  provides  some  evidence 
that  the  offeror  would  have  a  low  probability  of 
success  In  completing  the  contracted  casks. (6)  In 
addition,  the  results  of  a  SEE,  whether  or  not 
successfully  completed,  give  some  visibility  Into 
possible  problem  areas  In  the  offeror's 
developmental  methodologies  and  provide  additional 
Information  to  be  used  during  the  source  selection 
process.  This  Insight  also  Identifies  areas  In  the 
offeror's  software  engineering  design  methodology 
that  must  be  given  additional  attention  at  the 
start  of  the  acquisition  phase. 

Typically  during  a  procurement,  an  offeror's 
proposed  plans  are  evaluated  during  proposal 
evaluations.  Areas  of  the  proposed  plans  that  are 
evaluated  Include  the  sections  regarding  the 
requirements  analysis,  design  methodologies,  and 
the  coding  techniques  to  be  used. (3)  Additionally, 
the  proposed  staffing  levels  are  also  reviewed. 

The  evaluation  of  the  plans  Is  designed  to  give  the 
Source  Evaluation  Board  (SEB)  some  Insight  Into  the 
offeror's  proposed  methodologies  concerning 
software  development.  Tills  paper  evaluation, 
however,  does  not  provide  any  Insight  Into  the 
offoror's  actual  Implementation  of  the  plans. 

While  they  may  be  Judged  as  adequate  during  the 
technical  evaluation,  the  actual  Implementation  of 
the  plans  may  be  well  below  the  required  SEB 
standards.  As  a  result  of  Improper  Implementation 
of  the  plans,  schedule  slippage  and/or  cost 
overruns  are  likely  to  occur.  To  help  avoid  an 
occurrence  of  this  type,  MITRE  personnel  developed 
a  SEE  as  a  non-standard  method  to  be  used  during 
source  .selection  for  evaluating  not  only  an 
offeror's  SUP  but  also  the  offeror's  expertise  In 
the  proposed  software  development  approach. (5,6,7) 

A  SEE  provides  Insight  Into  the  offeror's  software 
development  approach  by  test.'ng  the  offeror's 
proposed  methodology. (S)  This  Is  demonstrated 
through  the  offeror's  design  and,  when  required, 
Implementation  of  a  small  exercise  system.  This 
exercise  system  provides  the  opportunity  to 
evaluate  the  offeror's  ability  to  use  modern 
software  engineering  principles,  implement  the 
proposed  plans,  and  organize  a  team  for  a  SEE  that 
Is  knowledgeable  In  both  the  proposed  development 
methodology  and  the  selected  Implementation 
language.  Unless  the  Implementation  language  Is 
specified  In  the  contract,  a  SEE  is  designed  as  an 
exercise  independent  of  language  and  development 
methodology.  It  Is  formulated  so  that  each  offeror 
can  demonstrate  the  proposed  design  and 
Implementation  methodology  to  be  used  during  the 
actual  system  development  activity. 

2.0  SEE  IMPLEMENTATION 

The  actual  implementation  of  a  SEE  is  divided  Into 
three  activity  areas:  1)  preparation,  2)  conduct, 
and  3)  evaluation.  A  milestone  chart  depicting  the 
overall  implementation  is  contained  in  Table  1. 


Ilat.rtElgd  Activity 

Prepare  RFP  Develop  SEE  Requirements. 

Conduct  Dry  Run. 

Develop  Documentation. 
Develop  Specific  Evaluation 
Criteria. 

Release  RFP  Finish  Developing  Specific 

Evaluation  Criteria. 

Accept  Proposals  SEE  Development  by  Offeror. 

Initial  Evaluation. 

On-Site  Review. 

Final  Evaluation. 


Award  Contract 


The  preparation  of  the  SEE  Is  concurrent  with  the 
preparation  of  the  Request  for  Proposal  (RFP) 
package.  Preparation  for  a  SEE  is  divided  Into 
three  overlapping  tasks:  1)  development  of 
requirements,  2)  conduct  of  a  dry  run,  and  3) 
development  of  documentation. 

During  this  period  clear  and  succinct  exercise 
system  requirements  are  developed  by  the 
contracting  agency.  To  be  meaningful  the  exercise 
system  must,  as  a  minimum,  be  relevant  to  the 
mission  of  the  new  system.  It  must  also  have  the 
appropriate  size  and  complexity  to  allow  rite  design 
to  be  completed  within  the  CovernmenL-lmposed  time 
constraints.  Unless  the  competing  contractors  are 
already  under  contract  to  the  Covernacr.t  (as  In  the 
case  of  the  AAS) ,  a  SEE  requirement  cannot  be  part 
of  the  actual  system  requirements.  Therefore,  the 
SEE  requirements  are  written  In  such  a  way  as  to 
reflect  the  critical  functional  requirements  of  the 
proposed  system  (l.e.,  If,  as  In  the  case  of  the 
AAS,  the  proposed  system  is  to  be  an  I/O  Intensive 
system,  then  the  requirements  would  be  designed  to 
stress  I/O  operations  that  are  comparable  with  the 
proposed  system). 

To  verify  that  the  exercise  system  requirements  are 
Indeed  reflective  of  the  oVerall  system 
requirements,  a  dry  run  should  ba  conducted  by 
contracting  agency  personnel  who  will  be  Involved 
with  the  evaluations.  During  this  dry  run  the 
exercise  system  requirements  can  be  modified  to 
ensure  that  the  exercise  requirements  that  are 
presented  to  the  offerors  are  both  distinct  and 
succinct.  A  set  of  ground  rules  that  must  be 
followed  by  each  offeror  when  conducting  the 
exercise  are  also  developed  at  this  time. (6)  Some 
examples  of  the  ground  rules  that  should  be 
specified  are: 

1.  Developmental  time  frame. 

2.  The  make-up  of  the  offeror's  SEE  team. 

3.  Required  hardware  (if  appropriate). 

4.  Detailed  requirements  (e.g.,  performance 
requirements) . 
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Tito  documentation  l*  then  developed  co  Include  the 
epproprUce  stipulation*  In  the  Request  For 
Proposal  (RFP)  package.  The  Instructions  (or 
Proposal  Preparation  (IFPF)  and  the  Section  .1 
Evaluation  Criteria  are  Modified  to  Include  this 
documentation. (5)  The  IFPP  Must  be  Modified  to 
Include  the  preliminary  SEC  Instructions  which 
describe  the  areas  to  be  evaluated  and  the  overall 
scope  of  the  exercise.  The  Section  M  evaluation 
criteria  are  Modified  to  present  to  each  offeror 
the  overall  ground  rules  for  the  exercise  and 
discuss  the  general  evaluation  criteria.  Finally, 
the  exercise  system  requlrceents  are  documented  In 
detailed  Instructions  that  are  provided  to  oacIi 
offeror  after  the  receipt  of  the  proposals. (0] 

During  this  time  period,  the  detailed  evaluation 
criteria  that  are  to  be  used  by  the  SEE  Evaluation 
Teaa  (SET)  (see  Section  2.3)  are  developed.  These 
evaluation  crlterU  are  used  during  both  the 
Initial  (In-house)  and  on-slte  evaluations  (see 
Section  2.3).  These  criteria  are  established  to 
provide  consistent  guidelines  for  the  evaluation  of 
the  submitted  SEE  material. (8)  These  guidelines 
are  also  used  to  place  eaphasls  on  the  most 
critical  aspects  of  the  exercise. 

2.2  SEE  Conduct 

Upon  submission  of  the  proposal  each  offeror  is 
provided  with  a  set  of  detailed  Instructions  that 
Includes  the  exercise  system  specification,  the 
specific  ground  rules  for  conduct  of  the  exercise, 
and  the  time  allocation  for  the  exercise. 

During  the  conduct  of  a  SEE  each  offeror  develops  a 
conplete  software  architecture  for  the  exercise 
system  to  Include  a  requirements  analysis,  a 
preliminary  doslgn,  and  a  detailed  design.  As  part 
of  this  design  phase  each  offeror  must  follow  the 
proposed  design  analysis  methodologies,  as 
documented  in  the  proposed  plans,  that  were 
submitted  with  the  technical  proposal.  Also,  all 
proposed  cools  to  be  used  during  the  actual  system 
development  activity  should  be  exorcised  to  the 
maximum  extent  possible  during  the  development  of 
the  exercise  system. 

At  tho  end  of  the  development  phase,  tho  offoror 
submits  all  requirements  analysis  and  design 
products  (both  textual  and  graphic)  that  are 
generated  as  part  of  the  SEE.  This  documentation 
should  also  Include  all  intermediate  products 
developed.  All  changes  to  the  proposed  plans  that 
wore  Identified  as  part  of  the  exercise  activity 
muse  also  be  submitted.  After  acceptance  of  the 
offeror's  SEE  products,  there  should  be  no 
Interaction  between  the  SET  and  the  offoror' s 
personnel.  Also,  after  the  acceptance  of  the 
submittal,  no  updating  of  the  material  should  bo 
allowed.  For  ease  of  review,  all  products  that  are 
submitted  should  bo  presented  in  both  hard  copy 
form  and  in  machine-readable  format. 

2.3  SEE  Evaluation 

The  SEE  Evaluation  Team  (SET)  should  consist  of 
members  of  the  cognizant  Government  agency,  and  a 


number  of  additional  technical  advisor*.  The 
evaluation  teaa  Member*  should  have  a  background  In 
overall  software  engineering  principle*  and  be 
knowledgeable  in  both  tho  offeror'*  proposed  design 
methodologies  and  the  proposed  implementation 
language.  Hie  SET  should  be  divided  Into 
evaluation  groups  according  co  Individual 
expertise. (6)  Although  responsible  for  specific 
areas  during  the  evaluation,  frequent  group 
Interaction  should  be  encouraged. 

The  evaluation  approach  is  divided  into  three 
phases  l)  the  Initial  evaluation.  2)  the  on-*lco 
review,  and  3)  the  final  evaluation.  The  time 
specified  for  each  phase  Is  tho  approximate  time 
necessary  for  the  conduct  of  each  review  phase  for 
the  type  of  SEE  that  Is  depicted  in  this  paper. 

The  actual  times  for  each  evaluation  phase  will 
vary  depending  on  the  specifics  (complexity)  of  the 
actual  exercise. 

Upon  receipt  of  the  offoror**  SEE  product*,  the 
initial  evaluation  1*  conducted  u*lng  the  offeror'* 
proposed  plans.  Tills  review,  employing  the 
previously  generated  evaluation  criteria.  Is  used 
to  determine  If  the  exercise  wa*  developed  in 
accordance  with  the  proposed  plans  and  It  the 
proposed  design  methodologies  are  adequate  to 
develop  the  overall  product.  The  end  result  of 
this  evaluation  Is  the  identification  of  the 
strength*  and  weaknesses  of  the  offeror'*  SEE 
product*  and  design  methodologies.  In  addition, 
questions  to  be  asked  during  the  on-slte  review  are 
generated. (?)  Although  no  specific  time  frame  Is 
set  for  thi*  evaluation,  experience  ha*  shown  that 
thl*  Initial  evaluation  should  t*ko  no  longer  thsn 
one  weok  per  offeror. (7,8) 

The  second  phase  of  the  evaluation  Is  the  on-slte 
review.  Tho  purpose  of  the  on-slte  review  Is  to 
verify  the  Information  gathered  during  the  Initial 
review  and  obtain  additional  Information  necessary 
to  complete  the  exercise  evaluation. |7]  This  on- 
slto  review,  conducted  by  the  SET  after  Its  Initial 
evaluation  of  SEE  products,  consists  of  a  briefing 
given  by  the  offeror  and  should  highlight: 

1.  Software  Development  Foldors  (SDFsl  for  each 
unit  designed. 

2.  Tools  used  to  conduct  the  exorcise. 

3.  Changes  Co  Che  SDF. 

it.  Lessons  learned. 

5.  Rncord  of  staff  C'.mo  expended. 

6.  Experience  level  of  personnel. 

7.  Estimate  of  computer  resource  utilization. 

8.  Amount  of  Quality  Assuranco  Interaction. 

9.  SEE  team  member's  levol  of  expertise  In  the 
proposed  language. 

During  this  briefing  the  offoror  should  provide 
answers  to  questions  concerning  various  aspects  of 
the  exercise  system.  This  on-slte  evaluation 
should  last  for  approximately  one  day  per  offeror. 

The  third  phase  of  the  evaluation  is  the  final 
evaluation.  This  period  should  be  used  co  update 
the  initial  evaluation  using  tho  Information 
gathered  during  the  ln-house  review.  This  period 
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1*  *l*o  used  CO  develop  the  formal  evaluation 
report  chat  1*  submitted  co  the  SES.  The  final 
review  should  l**c  for  approximately  on*  v«*k. 

3.0  CONCLUDING  OSSERV'ATZOSS 

A  SEE  can  he  an  extremely  beneficial  «ourc* 
selection  evaluation  technique.  Requiring  each 
offeror  to  develop  SEE  produce*  allow*  the  SES  co 
evaluate  what  che  offeror  can  really  do,  a.i  oppoxed 
co  vhac  che  offeror  *ay*  can  he  done.  Hie  early 
vlalblllty  Into  the  offeror'*  *oftv*re  development 
methodology,  In  conjunction  with  che  review  of  che 
propo*ed  plan*,  provide*  discriminating  *oure« 
selection  Information,  Thl*  Information  Include* 
the  offeror's  ability  co  Implement  che  proposed 
plans,  che  offeror's  expertise  In  che  proposed 
design  methodology  and  cool  set,  and  the  offeror's 
experience  with  the  proposed  design  language  and, 
when  required,  the  proposed  Implementation 
language. (7,8) 

A  SEE  provides  an  excellent  vehicle  with  which  co 
Identify  early  problems  In  the  offeror's  software 
development  approach.  The  requirement  to  develop 
an  actual  system  design  provides  visibility  Into 
the  proposed  design  methodology  and  che  capability 
to  Identify  Incomplete  methodologies.  By 
uncovering  problems  cerly,  the  Government  and  che 
contractor  are  able  to  concentrate  on  these 
problems  at  che  start  of  tho  acquisition  phsse 
(full-scale  developaenc)  rather  then  waiting  until 
the  actual  development  phase  has  been  completed  and 
the  deficiencies  become  more  costly  co  correct. 

Conducting  u  SF.E  during  tho  source  selection 
process  can  be  costly  co  both  the  Government  and 
the  offerors.  On  both  sides,  It  requires  an 
investment  of  people,  time,  and  money.  Tho  conduct 
of  a  SEE  cay  also  add  significant  time  to  the 
source  selection.  Although  on  che  surface  a  SEE 
appears  to  be  very  beneficial,  more  studies  are 
needed  as  co  the  cosc/bcneflcs  ratio  to  detoralno 
If  it  should  be  required  for  overy  project.  While 
It  Is  apparent  that  a  SEE  Is  of  great  bonoflc  to 
large  projects  (e.g.,  AAS),  che  value  of  tho  uso  of 
a  SEE  during  source  selection  for  smaller  projeecs 
muse  be  determined  on  a  case  by  case  basis. 

Finally,  a  SEE  can  only  be  worthwhile  during  source 
selection  if  the  exercise  system  requirements  are 
tailored  to  tho  Individual  project.  This  fine- 
tuning  of  the  SEE  requirements  can  only  bo  dona  by 
porsonnol  that  are  Intimately  aware  of  the  needs  of 
the  particular  project.  The  use  of  an  off-the- 
shelf  (generic)  SEE  will  not  provide  tho  source 
selection  Information  or  Information  necessary  for 
addressing  problems  early  after  the  contractor  has 
been  selected. 
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An  Approach  to  Ada  Compiler  Acceptance  Testing 

E.G.  Amoroso 
T.D.  Nguyen 

AT&T  Bell  Laboratories 


Abttncr.  Thk  paper  daacriba*  m  ongoing  acceptance  tcrun* 
approach  bain*  i*«J  at  AT&T  Ball  Labor  afcxi**  and  AT&T 
Tachnologiaa  to  evahtaia  a  port  of  the  Verdi*  Ad* 
Development  Syrian  (VADS)  to  tb«  AT&T  3B  family  of 
cmnputot*.  The  approach  ha*  been  darignad  to  Marcia*  lb* 
compiler  in  a*  realUlic  a  aatting  at  poaaibk  from  aeveral 
different  point!  of  view.  It  i*  ahown  that  lb*  evaluation 
provida*  aeveral  oilier  important  btnefiu  a*  wall. 

1.  Introduction 

During  the  past  two  years,  AT&T  and  Verdi*  have  been 
involved  in  an  effort  to  port  the  Verdi*  Ada 
Development  System  (VADS)  to  the  AT&T  3B  family  of 
computers.  As  the  port  nears  completion,  AT&T  has 
begun  to  implement  an  acceptance  testing  approach  that 
was  designed  to  provide  useful  information  about  the 
quality  of  the  VADS  compiler  and  ks  environment.  The 
approach  is  characterized  by  the  following  points: 

•  All  components  of  compiler  quality  may  be  exercised 
effectively. 

•  The  compiler  is  evaluated  in  a  highly  realistic  setting. 

•  The  compiler  is  evaluated  from  several  points  of 
view, 

•  Programmers  with  little  or  no  background  in  Ada 
may  contribute  productively. 

•  Staff  and  resources  may  not  have  to  be  solely 
allocated. 

•  Existing  and  ongoing  projects  may  directly  benefit. 

•  The  evaluation  staff  gains  valuable  Ada  experience  in 
realistic  settings. 

•  The  approach  may  also  be  used  to  'test”  systems 
other  than  Ada  compilers. 

This  paper  provides  a  rationale  for  and  description  of  the 
acceptance  testing  approach.  A  description  of  the 
implementation  of  this  approach  for  the  VADS  compiler 
is  also  included. 

2.  Evaluation  Alternatives 

As  stated  above,  as  completion  of  the  VADS  compiler 
port  neats,  an  investigation  into  the  quality  of  the 
compiler  in  the  target  AT&T  UNIX®  System  V 
environment  has  begun.  The  first  step  in  the 
investigation  was  to  examine  potential  acceptance  testing 
alternatives. 


The  first  approach  considered  involved  simply  using  the 
Ada  validation  test  suite  to  gain  some  experience  with 
the  compiler  and  its  environment  It  was  thought  that 
although  Verdix  had  already  run  these  tests,  the  process 
of  re-running  them  at  AT&T  might  provide  valuable 
information  about  the  quality  of  the  compiler.  The 
problem  with  this  approach,  however,  (beyond  the 
duplicated  effort),  was  that  many  of  the  components  of 
compiler  quality  could  not  be  tested  effectively.  Running 
a  collection  of  compilation  tests  that  have  already  been 
developed  is  but  a  single  measure  of  how  well  a 
compiler  will  help  human  beings  get  their  jobs  done. 
Other  important  components  of  quality  such  as  reliability 
(producing  identical  results  for  identical  inputs),  usability 
(helping  new  users  without  hampering  experienced  ones), 
code  efficiency,  and  support,  must  also  be  taken  into 
account  in  any  acceptance  testing  approach.  In  addition, 
suck  an  approach  would  provide  liule  information  about 
how  well  the  compiler  fit  into  the  target  UNIX 
environment. 

With  this  fat  mind,  a  second  potential  acceptance  testing 
approach  was  considered  based  on  the  design  of  a 
collection  of  our  own  compiler  penetration  tests. 
Assuming  there  were  no  obvious  bugs  in  the  compiler, 
these  penetration  tests  would  most  likely  explore  the  dark 
recesses  of  the  VADS  compiler  in  search  of  obscure 
bugs.  The  development  of  these  tests  would  obviously 
provide  valuable  information  about  the  correctness  of  the 
compiler,  as  well  as  information  on  the  usability, 
reliability,  and  other  components  of  quality.  The 
problem  with  the  approach,  however,  was  that  it  would 
have  encouraged  most  of  the  effort  to  be  placed  in  areas 
of  the  compiler  that  are  rarely  used  fif  ever).  The  bulk 
of  one's  attention  ought  to  be  placed  on  those  areas  that 
will  be  most  used  (i.e.,  a  robust  approach).  In  addition, 
good  penetration  tests  require  the  full  attention  of  a 
dedicated  staff,  and  once  the  tests  are  completed,  they 
have  little  value  beyond  their  intended  function.  For 
these  reasons,  the  "penetration"  acceptance  testing 
approach  was  rejected. 

A  third  approach  considered  for  the  acceptance  testing 
involved  simply  putting  the  compiler  into  immediate  use 
on  an  existing  Ada  project  Obviously,  such  an  approach 
would  provide  a  highly  realistic  evaluation,  since  the 
compiler  would  be  exercised  in  a  real  setting.  However, 
the  approach  was  rejected  for  two  reasons.  First  of  all,  a 
particular  project  might  require  heavy  reliance  on  one 
feature,  but  might  at  the  same  time  not  require  another 
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feature  at  all.  This  situation  could  bias  the  evaluation 
somewhat  and  allow  certain  aspects  of  die  compiler  to  |o 
unevaluated.  A  second  reason  the  approach  was  rejected 
was  that  it  was  not  feasible  for  any  ongoing  AT&T 
Ada-related  project  to  terminate  the  use  of  the  existing 
Ada  compiler  without  severely  impacting  its  progress  and 
the  schedule. 

Finally,  a  compiler  acceptance  testing  approach  was 
agreed  upon  that  provided  most  of  the  benefits  of  the 
above  mentioned  alternatives  without  many  of  the 
drawbacks.  In  fact,  this  approach  provided  several 
benefits  that  no  other  alternative  could  provide.  The 
approach  is  based  on  the  notion  that  ongoing  non-Ada 
projects  and  work  efforts  can  be  used  as  a  framework  for 
evaluating  an  Ada  compiler.  That  is,  work  that  is 
already  being  planned  or  started  that  does  not  carry  an 
explicit  ‘programming  language*  requirement,  could  be 
done  in  Ada  ttfbig  the  compiler  to  be  evaluated.  This 
approach  has  several  attractive  side -effects.  For  one,  it 
lends  to  provide  a  well-rounded  act  of  realistic  situations 
within  which  to  evaluate  the  compiler.  For  instance, 
several  in  our  local  community  at  Bell  Laboratories  were 
interested  in  providing  a  secure  distributed  bulletin  board 
capability.  Although  the  original  plan  had  been  to  build 
the  system  using  C,  there  was  no  reason  why  it  could  not 
be  done  in  Ada.  A  second  important  characteristic  of  the 
approach  is  that  resources  and  staff  may  not  have  to  be 
explicitly  allocated.  If  the  work  is  being  planned 
anyway,  the  evaluation  docs  not  cause  a  significant 
allocation  increase.  Also,  unlike  the  penetration  tests, 
these  "tests'  will  continue  to  be  useful  even  after  the 
evaluation  is  complete.  Perhaps  the  most  important 
aspect  of  the  approach,  however,  is  that  it  forces 
programmers  and  engineers  who  would  net  normally  be 
involved  in  such  an  effort,  to  gain  Ada  development 
experience. 

3.  Applying  the  Approach 

Two  important  considerations  were  taken  into  account  in 
selecting  the  type  of  work  to  be  done  in  Ada  for  the 
evaluation: 

•  That  several  concerns  (e.g.,  security,  networking, 
performance),  were  likely  to  be  of  the  utmost 
importance  in  future  applications  that  might  use  the 
compiler. 

•  That  the  work  should  be  of  varying  degrees  of 
difficulty,  and  should  cause  as  much  of  the  compiler 
to  be  exercised  as  possible. 

In  this  section,  three  ongoing  AT&T  efforts  are  described 
that,  collectively,  seem  to  meet  the  above  considerations. 
It  should  be  mentioned,  however,  that  this  work  is 
ongoing,  and  in  fact,  more  efforts  may  be  added  in  the 


future.  It  should  also  be  noted  that  the  very  nature  of  the 
approach  is  quite  conducive  to  such  additional  work 
efforts.  One  final  point  worth  mentioning  is  that  the 
approach  is  also  appropriate  for  evaluating  a  compiler 
before  it  is  purchased  and  ported. 

3,1  A  Novel  Password  Generator 

Computer  security  has  become  an  important  concern  in 
most  of  the  areas  that  Ada  is  likely  to  be  used  (e.g., 
critical  embedded  applications,  communications  systems, 
etc.).  With  this  in  mind,  it  was  determined  that  our 
acceptance  testing  should  include  some  security-related 
work. 

It  turned  out  that  the  local  systems  engineering  team 
involved  in  the  design  and  development  of  System 
VIMLS,  a  security-enhanced  UNIX  System  V-bascd 
operating  system  l  FI  ink  88],  had  been  interested  in 
prototyping  a  rather  novel  approach  to  password 
generation.  The  approach  combines  the  best  features  of 
automatic  password  generation  (i.e.,  the  removal  of  all 
blatantly  bad  passwords  from  a  system),  with  the  best 
features  of  user-defined  passwords  (i.c.,  their  mnemonic 
nature). 1 

In  a  system  that  supplies  an  automatic  password 
generator,  a  fixed  length  password  is  generated,  and 
although  users  are  allowed  several  choices  of  strings, 
eventually  one  of  the  strings  has  to  be  chosen.  Because 
the  user  has  no  control  over  its  contents,  the  password  is 
rarely  mnemonic.  (It  is  worth  mentioning  that 
pronounceable  docs  not  imply  mnemonic!) 

In  systems  that  allow  users  to  generate  their  own 
passwords,  on  the  other  hand,  the  mnemonic  issue  is 
often  taken  to  Us  extreme.  Rather  than  having  a 
collection  of  passwords  that  are  of  an  equivalent  nature 
(in  terms  of  their  guessability),  as  in  a  system  with  an 
automatic  password  generator,  systems  with  user  defined 
passwords  usually  have  some  excellent  passwords,  some 
average  ones,  and  some  terrible  ones.  Combining  this 
fact  with  the  notion  that  an  operating  system  is  usually 
about  as  secure  as  its  weakest  password  leads  to  a 
distressing  conclusion  about  such  systems. 

The  combination  system  that  is  being  coded  in  Ada 
would  allow  a  string  of  fixed  length  determined  by  an 
administrator,  to  be  passed  to  users.  Users  would  then 
"change’  this  string  to  a  password  that  is  both  mnemonic 
and  pronounceable.  The  rules  for  such  "changing"  could 
allow  prepending,  inpending,  or  postpending.  For 


1.  The  approach  wu  fir>(  detcribed  to  ui  by  the  AT&T  Bell 
Laboratoriet  Computer  Center  luppoit  group. 
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example,  if  the  string  'U'd'  was  passed  to  a  user  by  the 
password  generator,  then  the  user  could  change  the  string 
to  ’UNlXVAda'  thus  preserving  the  ordering  of  the 
original  string. 

Obviously,  our  description  of  this  system  is  not  nearly 
complete  and  only  provides  a  lavor  of  what  is  being 
built,  but  the  description  points  out  seven  I  issues  that  are 
relevant  to  our  present  discussion.  First  of  all,  writing 
an  Ada  program  to  implement  such  a  feature  is  not  an 
unusually  difficult  exercise.  As  a  result,  this  is  a  good 
example  of  an  effort  that  Is  suitable  for  a  novice 
programmer  to  tackle.  By  using  a  novice  programme,  in 
the  acceptance  testing,  one  stands  to  gain  valuable 
information  about  the  usability  of  the  compiler  from  a 
novice  point  of  view.  In  addition,  valuable  feedback  on 
error  messages,  user  documentation,  and  environmental 
tools  is  also  obtained.  A  second  important  issue  is  that 
the  program  requires  use  of  most  of  the  ’mainstream’' 
features  of  the  Ada  language  -  the  so-called  Pascal 
subset  Such  features  arc  often  used  in  Ada  programs, 
and  are  thus  most  appropriate  for  acceptance  testing.  A 
final  issue  is  that  the  program  will  clearly  remain  usable 
long  rfter  the  acceptance  testing  has  been  forgotten. 
This  valuable  side-effect  of  our  approach  cannot  be 
underestimated. 

32  C++  vs.  Ada  Benchmarking 

The  issue  of  performance  is  one  that  clearly  needed  to  be 
addretaed  as  part  of  the  acceptance  testing.  Ada 
performance  is  a  concern  that  had  been  coming  up 
repeatedly  during  the  preparation  of  language  trade 
studies  for  several  Ada-related  proposals,  and  many  of 
our  colleagues  had  expressed  a  particular  interest  in 
comparing  the  performance  of  Ada  to  that  of  the  object- 
oriented  language  C++  (Stroustmp  86].  As  a  result  it  was 
decided  that  as  part  of  the  acceptance  testing,  a  collection 
of  benchmark  programs  (some  of  which  already  existed 
in  C++)  would  be  coded  in  Ada  and  C++  to  determine 
the  relative  code  efficiencies.  Obviously,  such  an  effort 
would  also  reveal  other  important  comparisons  as  well, 
such  as  the  relative  usability  and  reliability  of  the  two 
languages. 

An  important  characteristic  of  this  benchmarking  effort  is 
that  it  docs  not  require  a  specified  level  of  minimal  Ada 
expertise.  The  complexity  and  accuracy  of  the 
benchmarks  would,  of  course,  depend  on  the  experience 
of  the  programmer,  but  clearly,  even  a  novice  Ada 
programmer  could  design  useful  benchmarks  that  would 
provide  valuable  information.  Another  desirable 
characteristic  of  this  benchmarking  effort  is  that  it 
involves  C++  programmers  and  enthusiasts  in  the  Ada 
testing  effort  Under  more  traditional  acceptance  testing 
circumstances,  these  programmers  might  not  be  interested 
in  testing  the  Ada  compiler,  but  given  the  challenge  of 


comparing  it  to  a  language  that  they  are  interested  in, 
provides  the  necessary  incentive. 

It  should  also  be  noted  that  the  results  of  the  benchmark 
remain  useful  (c.g.,  for  proposal  trade  studies,  etc.)  after 
the  acceptance  testing  has  been  completed. 

33  Distributed  Bulletin  Board 

A  thin!  important  area  that  is  already  having  a  major 
influence  on  many  Ada-related  projects  and  efforts  is 
secure  networking.  As  a  result,  it  was  determined  that 
the  acceptance  testing  effort  should  include  some  secure 
network-oriented  project.  It  turned  out  that  several  in 
our  community  at  AT&T  Bell  Laboratories  had  been 
interested  in  providing  a  local  secure  distributed  bulletin 
board  system  across  our  distributed  configuration  of 
secure  computers  running  System  V/MLS.  Although 
initial  prototypes  of  the  system  had  been  built  in  C,  there 
appeared  to  be  no  reason  why  it  could  not  be  built  in 
Ada. 

The  bulletin  board  would  maintain  a  record  of  all 
privileges  associated  with  a  particular  user.  Reports 
posted  to  the  bulk  tin  board  would  be  readable  by  only 
those  users  with  the  appropriate  privileges.  Reports 
posted  to  the  board  would  inherit  the  privikgcs  of  the 
user  posting  the  report.  An  administrator  would  maintain 
the  contents  of  the  board. 

Implementing  such  a  system  in  a  distributed 
configuration  of  secure  computers  would  likely  require 
the  use  of  most  of  the  features  of  the  Ada  larjuagc 
including  packages,  tasking,  generics,  and  exceptions.  It 
would  also  require  such  features  as  the  interface  to  the  C 
programming  language.  As  a  result,  such  a  project 
would  require  at  least  some  Ada  programming  maturity. 
The  project  would  result  in  feedback  on  the  quality  of 
the  compiler  from  a  more  experienced  user.  The 
usability,  reliability,  documentation,  environment,  and 
code  quality  of  the  compiler  would  all  be  rc-evaluated, 
but  from  a  more  sophisticated  point-of-view,  and  in 
terms  of  systems,  rather  than  just  programs. 

4,  Concluding  Remarks 

In  conclusion,  an  acceptance  testing  approach  has  been 
described  that  combines  the  best  features  of  several 
traditional  acceptance  testing  approaches  into  a  collection 
of  small  projects  that  result  in  work  that  is  useful  even 
after  the  acceptance  testing  has  been  completed.  It 
should  be  pointed  out  that  although  the  approach  has 
been  described  in  terms  of  the  AT&T/VADS  porting 
effort,  the  approach  is  not  Ada-specific  at  all,  and  could 
be  used  for  (he  testing  of  any  system  that  is  being 
considered  for  installation  or  use. 
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I.  INTRODUCTION 

Then:  Km  hoc*  *  considerable  amount  of  interest  i* 
the  use  cf  software  metric!  to  describe  the  degree  kj  which 
*  piece  Of  Kf  l  lore  pcwwssc*  *  give*  attribute.  Metrics 
have  heat  devekipcd  using  the  Meat  that  the  primary  com* 
pkilty  of  o  program  fat  the  number  and  type  of  Operand! 
and  operator*.  or  the  number  of  program  hone  Set,  or  the 
degree  and  type  of  kucrtonneciion  between  the  modulot 
that  male  up  the  program. 

ThU  nod  hat  assumed  special  significance  fat  die 
Ada  environment  Ada  was  designed  in  large  pm  k)  Sup- 
pew  the  development  of  large  « ftware  project*  which  are 
bulk  tiring  the  technique*  of  data  abstraction.  Thu*  an 
important  use  of  metric*  fat  In  assessing  the  quality  of  Ad* 
software  project*.  It  ha*  been  clear  for  tome  lime  that  no 
tingle  number  suffice*  to  measure  the  quality  of  a  piece  of 
toft  ware.  Typically,  a  piece  of  software  ha*  many  attri- 
bo'c*  (portability,  readability,  verifiability,  (ompkaky  of 
underlying  algorithm,  oompkiuty  of  implementation,  etc.) 
which  are  mcanirtd  by  various  software  metric*.  Much  of 
the  research  on  loftware  metric*  It  difficult  to  replicate 
became  of  the  proprietary  nature  of  the  code  being  meal- 
tired. 

The  reference*  |1).  |S],  and  19),  describe  some  gen¬ 
eral  purpose  result*  In  thl*  area,  while  the  paper*  (3),  (4), 
(6),  PI  and  |X|  describe  some  metric*  that  arc  specific  to 
the  language  Ada. 

tn  this  note,  we  cipiorc  some  of  the  attributes  of  a 
large  bloch  of  code  written  by  a  large  collection  of  pro- 
grarrimer*  with  the  specific  intention  of  malting  the  cole 
available  far  common  use.  The  code  considered  here  It 
the  Ada  Repository,  which  at  the  time  this  paper  was  writ¬ 
ten  (July  18.  1988)  contained  more  than  S4  megabytes  of 
tut  with  approximately  1.1  million  line*  of  code  and  the 
rest  documentation.  Much  of  the  emphasis  of  the  reposi¬ 
tory  is  on  the  portability  and  reusability  of  the  code,  since 


thi*  was  a  primary  reason  far  the  creaticn  of  the  rcp.ni 
lory.  The  other  major  emphasis  is  on  die  maintainability 
of  the  code.  Code  can  be  ported  effectively  frtxn  one 
Installation  to  another  only  if  the  purpose  of  the  code  and 
any  specific  requirement*  about  related  hardware  an«l 
software  are  understood. 

We  note  that  there  Is  little  discussion  of  the  ihconrtt 
cal  nature  of  either  metrics  (n  general  or  Ada  specific 
metric*  In  particular  fat  this  paper;  the  emphasis  is  on 
determining  essential  attribute*  of  precisely  what  currently 
ciist*  in  the  Ada  Repository.  We  consider  the  Ada  Repo¬ 
sitory  a*  a  testbed  for  research  in  software  metric*  and 
note  that  the  availability  of  the  code  to  other  researchers 
can  aid  In  the  development  of  software  quality  metric*. 

This  work  Is  part  of  a  research  project  at  Howard 
University  to  apply  metrics  driven  design  to  large  software 
systems  during  most  phases  of  the  software  life  cycle 
This  project  (called  HUMAN  for  Howard  University 
Metrics  ANalyrer)  currently  consists  of  software  tools  for 
the  analysis  of  programs  written  in  C  and  Ada,  with  die 
tool*  being  written  in  the  appropriate  language.  Hie  work 
described  here  involves  the  Ada  version  of  HUMAN 
which  is  written  In  the  language  Ada  itself.  The  Ada  code 
for  HUMAN  is  written  fat  Meridian  Ada  running  on  AT&T 
PGJ31Q  *,  which  are  IBM  PC  AT  class  machines.  (Ihc 
repository  itself  contains  several  metric*  files  in  the  direc¬ 
tory  METRICS.  However,  the  McCabe  cyclomatic  c««i- 
pleaity  package  requires  access  to  lim  source  code  ef  an 
Ada  compiler  and  the  Halstead  Software  Science  Metric 
package  contains  over  1.1  megabyte;  lbs  is  far  too  luge 
for  an  AT  class  mcdiinc.  Therefore  we  wrote  our  own 
code.  Tlie  source  cxie  is  quite  small  and  die  Mendkn 
compiler  generates  fast  code  for  die  80286  processor.) 

2.  THE  ADA  REPOSITORY 

The  Ada  Repository  is  t>  collection  of  packages 
which  is  made  available  to  useJs  for  die  cost  of  die  d.vtu- 
l-aioL  mediem.  Die  Ada  Rqios.ior/  is  store  ■  on  die 
Defense  13.ua  Network  and  is  also  available  from  other 
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fOueiei,  The  Ada  Afcemtloo  Office  should  be  contacted 
(u  Afoem*t»<n  00  accessing  the  Ada  Reposhoty.  TheCfl- 
find  Intention  of  t*»t  Ad*  Repository  ww  w  provide  Add 
users  and  researcher*  wi*  an  opportunity  us  **c  a  Urge 
variety  cl  Ada  package*  in  Ac  if  work.  One  major  goal  of 
the  Repository  *w  to  provide  a  set  of  software  tom. 
patients  which  can  be  used  in  a  variety  of  appUtationt, 
Benefit*  include  the  diuonimum  of  Afomudon  to  many 
people  about  the  facilities  available  in  Ac  language  Ada. 
Much  of  (hit  information  it  teiwal  and  dec*  net  contain 
Ada  source  code.  Ifor  example,  the  directory*  ANSI* 
UM.  CROSS-REFERENCE,  EDUCATION,  ID- HUES, 
NEWS,  and  WIS-ADA-TOOLS  am  appro*  imatcly 
4fiUGt)0.  II  WO,  1670000,  14MP00.  JJJIOOO,  and  24  JO 
byte*  large  respectively,  and  contain  no  Ada  source  code. 

There  arc  a  total  of  JtO  package*  in  the  repository, 
written  by  more  than  91  different  programmer*  or  pro¬ 
gramming  team*.  Thu*  the  rtpetitery  rtprtacnt*  a  crow 
section  of  the  nature  of  cabling  code.  The  mean  number 
of  comment  line*  v  the  repository  b  216%,  Since  only 
23,7%  of  the  filet  k  the  repository  arc  source  filet,  only 
about  20%  of  the  repository  eontiats  Of  tint*  of  Adi 
source  code.  The  repository  rvprcxeou  a  cross,  section  of 
the  nature  of  cabling  code.  Many  people  have  com* 
mcnicd  that  the  -.ode  fat  Ac  repository  fat  of  uneven  qua), 
ity.  we  tec  Alt  at  an  advantage  fat  determining  the  actual 
State  of  affair*  in  the  Ada  community.  It  b  not  reasonable 
to  only  consider  the  quality  of  code  written  by  outstanding 
programmer*;  in  fact  only  60%  of  Ada  programmer*  arc 
above  average  art  Adi  programmer*. 

There  are  frequent  addition*  u  and  deletion*  from 
the  Ada  Kepotfaocy.  Thu*  to  have  a  common  bnttt  for 
evaluation,  we  consider  the  Ad*  Repository  as  it  tabled 
on  June  I,  I9M. 

The  Ada  Repository  consist*  of  1433  Ada  source 
code  filet,  documentation,  and  lest  filet,  it  also  contains 
the  <ANSI-LRM>  (ANSI  Language  Reference  Manual), 
ONUNE-DOC  (on-line  documentation),  and  <ADA> 
(information  on  how  to  use  the  Ad*  Reporter))  direc¬ 
tories.  In  this  paper,  we  only  dictuc  those  directories  Am 
contain  tturte  code.  The  filet  are  grouped  in  the  follow, 
mg  direetorvM  that  arc  Indicated  in  table  1. 

Of  the  J  tO  Ad*  source  code  files  in  Ae  repository, 
run  c  pretexted  here  on  270.  The  70  omitted  filet  were 
not  considered  because  they  contained  more  than  6000 
lines  of  code  etch.  Our  experience  wiA  the  HUMAN 
metrics  program  Is  Am  an  Ad*  source  code  {ms- 

gram  of  6000  Ifot*  of  Code  generates  at  least  20000 
separate  fokrej  *kd  Ait  exhausts  the  memory  of  the  PC 
used  for  this  project  levause  of  Ae  length  of  the  tokens 
and  the  need  for  associated  data  structures. 


3.  METHODOLOGY  FOR  METRICS  COLLECTION 
The  Ada  Repository  is  distributed  In  several  formats. 
The  forma;  chosen  for  this  project  was  UNIX  tar  format. 
Tire  repository  was  loaded  onto  an  ATAT  3R2/40O  com¬ 
puter  which  at  the  time  did  not  have  an  Ada  compiler  but 
did  have  a  reliable  upe  drive.  In  order  to  read  ail  of  the 
flcs,  Ae  system  variable  W Am/  had  to  be  increased  to 


allow  filet  of  kttgA  greater  than  I  MSI.  The  filet  were 
downloaded  to  ATJtT  IC  6310’t  which  arc  IBM  FC  AT 
claw  machine*.  All  of  the  automated  metric*  analyst*  of 
Ac  repository  wat  done  on  Ac  FC*  using  Meridian  Ada. 
Because  of  Ac  limited  capacity  of  Ae  FC**,  it  «at  neces¬ 
sary  to  split  up  a  few  filet  and  to  remove  *  few  formaumg 
commands  included  A  certain  filet.  The  few  filet  that 
were  divided  had  all  part*  subjected  to  automatic  weak* 
analyst*  and  Ac  total*  for  the  file*  arc  presented  A  Am 
p*cr. 

The  primary  automatic  metric*  computed  and 
presented  A  Ait  paper  are  the  Halstead  Software  Science 
Effort  and  Ac  McCabe  CycAmattc  Compkaky, 
IUIstatd‘1  metric  it  obtained  by  ClaisifyAg  all  executable 
statements  at  being  composed  of  operator'  A  at  (.  3, 
*,  a,  etc.  and  operand*  such  at  x,  7,  tie.  The  Software 
S«k*ec  Effort  l*  obtained  by  muhiplyAg  the  ta  pro*  ton 

(Af|  *Nj)fog(ni  *nj) 

by  a  constant  catted  Ae  Stroud  number  which  I*  often 
cstfanaicd  to  be  HL  Here  ,V,  ,/fj.ni  and  «j  xe  Ac 
number  of  operator*,  operand*,  ditslnct  eperyor*,  and  div 
tinct  operand*,  respectively.  This  metric  ws*  designed  A 
correlate  wiA  Ae  number  of  ‘menu)  discrimination*'*  per¬ 
formed  by  Ac  programmer.  Since  we  are  interested  A  Ae 
correlation  between  attribute*  of  the  software  and  Ac 
value*  of  various  metric*  applied  to  the  code,  w*$  have 
ignored  Ac  Stroud  .-lumber  and  used  Ae  natural  logarithm 
A  Halstead'*  metric,  foe  simplicity,  u  have  also 
rounded  Ae  value  of  Ac  Halstead  metric  to  >'x  nearest 
integer* 

McCabe'*  metric  ignore*  assignment  statements  and 
fauKad  emsiders  A*  Bow  of  Ac  program.  All  statement* 
A  a  program  are  considered  vertices  of  a  graph.  Edge* 
are  drawn  between  vertices  if  there  it  direct  connection 
between  two  statement*  by  a  loop,  conditional  branch,  or 
Ae  statement*  are  A  sequential  order.  McCabe'*  metric  i* 

l'-£+2P 

where  £  it  the  number  of  edges,  l'  it  Ac  number  of  ver¬ 
tices  and  P  it  Ac  number  of  separate  ports  (■  number  of 
subprograms  called,  including  Ae  nuin  program). 

McCabe  (£}  suggests  that  functions  or  procedure* 
wiA  a  cydomatic  complexity  greater  than  10  should  hs 
avoided  at  being  unstructured;  the  oolv  exception  to  Ait 
rule  of  Aumb  would  occur  only  when  Acre  are  care  state¬ 
ments  wiA  many  alternatives. 

For  cadi  Ada  source  code  file.  v-c  measured  Ac 
value*  of  Ac  variables 

FU  »  number  of  ptoiram  knits 
irr  n  total  lialsuoJ 
MT  ■  total  McCabe 
Mil  « Maximum  Halstead  of  any  unit 
mSt  •»  minimum  Halstead  of  any  unit 
MM  t  Maximum  McCabe  metric  of  any  unit 
mM  k  minimum  McCabe  metric  of  any  unit 
L  ■  number  of  lines 
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t*mm |  K  *Wvf  p/  K*tS  *ilh  (IWW 
the  result*  rf  lie  mewurernerxx  are  jiinn  tts  uHc  2. 

jMNee  cod*  fa  Ac  mewics  analyst*  w*t 
»{V«t4ma*cty  JCCO  (met  Iqpg  and  wag  fi#3J5  byte*  k*g 
K*»te?*c  of  Axwmcntxle'ni  The  rede  *w  pbeed  A 
Several  Adfct  same*  cede  (tee.  Thi*  I*  conAdeoWy  Aontf 
than  >he  wmKftMko  of  newly  JO.OOQ  line*  l*  Ac  Ole 
Mitca&re  and  Ac  adde.wM  I0.0CO  tine*  to  Ac  Ilk 
meviNr.w.  The  Me  tnwt » contain  jcvera! 

attempt* at  writing  Ac  lUtaead  metrfot  analysis  MMl 
fairer  cemtwriwsn  k  Kct»v<«  Ac  K?0O  Imc*  of  HUMAN 
»0d  Ac  approximately  WJ&X)  Use*  fee  metric*  analysis  A 
Ac  metrics  three  te*y. 

4,  ANALYSIS 

The  first  question  we  teniidrred  ww  horn  Ac  v*j- 
able*  correlated  *iA  one  another.  The  inphs  A  figure  l 
tufiot  Ax  Acy  sec  related.  Hdwctcr,  Ac  Uabwnd  end 
hfoCabe  me  trees  were  »  Urge  fa  *  tclatinly  wndl 
.  xr  of  file*  A*  Ae  cotteWoM  were  not  very  good. 
!-'.c  cwreUdon*  are  gire*  to  Ufck  3,  The  correlation*  me 
greatly  si  fix  ted  by  a  few  5k*  itaring  very  1*1*  whit*  of 
Ac  Halite*!  tie  McCabe  metric*.  sum  her  of  pevgr «  writ*, 
number  cf  Use*,  or  the  pcretntsge  of  comments  .  A  toot* 
more  *uti tries)  kChtriooc  k  to  ignore  Acte  ow Utrt  shot 
confuting  «hc  cortrUics  coefficient*.  We  did  nor-  do  Am 
A  At*  data  set  because  we  expect  to  expand  the  dm  col¬ 
lection  A  Isrgtr  Ads  source  code  file*.  The  low  correla¬ 
tion*  see  lively  to  he  Increased  when  Ac  additional  Urge 
Ads  source  file*  arc  snatysed. 

The  etwreUJon  did  not  improve  if  we  replac'd  a 
quantity  with  It*  density:  Aat  k  if  we  replaced  a  variable 
well  stiff  by  Ac  quantity  UHL,  Ac  correUtion*  showed 
buJe  change  sod  Aat  change  grncnUy  did  not  increase  Ac 
correlation.  Thc*c  resell*  are  wwnmarfred  in  table  4. 

The  Halstead  ami  McCabe  Metric*  are  called 
mtcroicvel  by  some  authors  because  Aey  only  consider  the 
actual  code  wium  program  units  and  do  not  consider  Ac 
level  of  interconnection  between  Ac  program  units.  In 
(6).  Ac  authors  described  computer  programs  fa  measur¬ 
ing  the  level  of  interconnection  between  Ads  package* 
using  At  number  of  WITH  statements  A  Ac  prelates  and 
comparing  this  to  Ac  number  of  package*.  No  metric*  for 
measuring  the  Aicrconreeciion  between  program  imk*  were 
used  A  At*  paper  since  newly  *11  of  the  code  A  the  repo¬ 
sitory  Is  composed  of  files  whh  one  package  per  file.  In 
addition,  most  cf  the  code  was  not  apparently  intended  a* 
stand-alone  code  rather  Aan  for  components  A  Ac 
development  of  large  syttemn  most  of  the  ettceptioni  to 
this  are  A  the  CempoAtnu  directory.  Consequently,  no 
mcjjurememt  of  AtcreonneciSens  between  program  unit* 
ate  given  A  paper. 

Portability  end  reusability  issue*  are  valid  topics  for 
research  since  the  Ada  RepcwWxy  originally  Intended  to 
showcase  portable  and  reusable  code.  We  begin  our  dis¬ 
cussion  of  these  issue*  viA  a  survey  of  some  existing 
work.  In  (4),  several  features  of  metrics  used  for  measur¬ 
ing  the  maintainability,  portability,  and  understartdability 
of  packages  were  discussed.  These  metrics  included  meas¬ 
urements  of  Ac  following?  pectogM,  generfer.  Interface: 


»  eifxr  tM|*ag «t.  and  swtcfiinc  code  wiifatit  Othre 
fxM*  A  Ax  paper  considered  were  those  due  kt 
verifiability,  programmer  understanding,  and  language 
k«cl.  It  *at  shown  A  Are  paper  Aat  no  metric  applied  at 
a  died  rime  A  Ac  bfc  cycle  co*M  provide  ret  accurate 
view  of  As  tun-time  ceroptexSty  of  a  ptogtsm  which  pc* 
mitt  Ac  dynamic  aerivat  An  of  task*. 

In  general,  these  metric*  had  Imlc  validity  for  Ac 
code  a  Ac  Ada  Repotkory,  the  axle  had  no  machine 
cede  intcnkmt  and  very  few  direct  imetfxa  to  oAer 
language*  oAer  than  the  language  of  the  compiler  A  Ac 
mccabcjuc  file  A  Ac  mwka  K<hdifecwry, 

The  Arretery  COMPONENTS  A  Ac  reporitoty  con* 
tatet  code  intended  A  be  wed  a*  software  rompanenu  A 
budding  reunbte  software.  There  are  *%  Ada  source  vide 
Met  A  At*  directory  which  Include  is  generic  package* 
Aa*  «t  to  be  Mandated  when  uwd  A  other  xoh>«re, 
For  example  Ac  fils  *«aek.*d*  contain*  a  set  rtf  generic 
pnekage*  which  may  be  used  for  typical  stxk  opererief-s 
such  m  pushing  an  Object  onto  Ac  suck,  pepping  ae 
object  off  Of  Ac  suck,  clearing  the  suck, «  thocku^  Ac 
stack  for  being  empty. 

The  file  ststttrryjib  eontata*  generic  sotting  routine* 
for  t'hich  Ae  fomal  geocrie  subprogram  parameter 
num  be  specified  wiA  any  Atiantiatiott:  this  is  specially 
important  for  sorting  record?  or  access  type*.  It  contain*  a 
large  sorting  function  which  can  eail  any  of  the  common 
sort  algorithm*  such  a*  quicksort,  bubble  son.  II  sort 
(which  we*  H-tret*),  selection  sort,  hcapsort.  A  teuton 
sort,  and  merge  son.  Several  of  Ac  sort  algorithm*  have 
both  recursive  and  new-recureive  versions.  All  of  the  son 
algorithms  are  appropriate  for  Internal  sort*  only.  The 
documentation  suggest*  splitting  files  into  manageable 
pieces,  sorting  Ae  pieces,  and  combi  nAg  them  wiA  a 
merge  sort.  This  procedure  might  alio  be  appropriate  foe 
external  files. 

A  simple  experiment  was  designed  to  determine 
some  of  Ae  problems  A  portability  and  reusability  of  Ada 
packages,  the  source  rode  fife  jiltccm/iMt  was  chosen 
a*  the  file  to  be  tested  for  portability.  An  attempt  to  com 
pile  Ae  file  showed  Aat  the  compilation  unit 
TOD.UTIUTIOS  al»  needed  to  be  compiled.  The  pack¬ 
age  TOD.UTIUTIES  was  found  in  .he  file  i eJMt.  This 
Aformarion  could  not  be  dticrmlncd  di.* telly  u*ir.g  Am 
package*  but  had  to  be  dektmined  by  cither  usAg  Ate 
operating  system  or  an  e.ttomal  daubate.  in  aAlition. 
Acre  are  restrictions  on  Ae  order  A  C-hieh  packages  van 
be  compiled.  This  pbenomencm  in  desermmlng  Apen- 
denre  and  compilatia"  cs'Av  is  well-known;  it  Is  the  rea¬ 
son  fa  many  article)  describing  library  maintenance  and 
source  code  control  and  for  Ae  rxtacncc  of  Ae  subdirec¬ 
tory  compHsiion-crikr  of  Ae  Ada  Repository.  The  pack¬ 
age  TOD_UTiUTlES  did  not  reiolve  all  of  Ae 
difficiAles;  compilation  of  TOD. UTILITIES  required 
compilation  of  mother  package  ailed 
SEARCH_UnUTIES  which  was  found  A  Ae  file 
starckada.  As  before,  identification  of  Ais  compilation 
unit  required  some  information  external  to  Ate  file.  It  is 
clear  Aat  Ais  process  can  be  quite  IcngAy  A  many  situa¬ 
tions. 
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TABLE  1:  DIRECTORIES 
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TABLE  2:  METRICS  TU  «  PROGRAM  UNTTS.  ITT  -  Halite*!  TOTAL  MT  -  McCabe  TOTAL  Mil  *  IhhteaJ 
MAX.  mil  ■  Halite*!  mb i.  MM  ■  McCabe  MAX,  mM  ■  McCabe  ml*.  L  ■  Number  cf  Una.  comm  ■  c emmcr.it 
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DENSITY 


Halit?*!  per  line 


McCabe  per  line 


HaUieaJ  pc*  program  unit 


McCabe  per  protram  unit 


Line*  per  program  unit 


III 


.230 


.•ISO 


.010 


-.(Mil 


.IRS 


irr 


.610 


.000 


.519 


.215 


•.153 


MT 


-309 


.224 


.213 


.250 


..OKS 


Mil 


.395 


.009 


.509 


.43S 


.322 


mil 


-.009 


-.107 


,4SX 


-331 


.010 


Ml 


■3C 


.OS 


-34 


.42 


212 


TABLE  4:  MORE  CORRELATIONS 


B3ttd( 

imti 

MTPU 

LTU 

ma 

MUM 

•07S 

mvrm 

Ea 

McCabe  per  line  (MTU 

■■ 

ITTTi 

..(HO 

.050 

.919 

mm 

■■ 

1.00 

.S9S 

..060 

nsaaansataGi 

Si 

n 

1 .00 

-.199 

1.00 

TABLES:  DENSID'  CORRELATIONS 
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J.  FURTHER  RESEARCH 

The  metrics  amly/er  HUMAN  has  been  applied  to 
most  of  the  tie*  hi  Ac  Ad*  Repository.  Dm*  collection 
will  be  obtained  for  die  remaining  targe  Ate*  a*  moo  a*  an 
Ada  compiler  with  larger  capacity  Is  obtained;  the 
intended  machine  fat  a  SUN  3  *idi  X  MR  of  main  memory 
and  a  dish  of  32?  MR.  The  result*  should  be  available  by 
the  time  that  this  paper  appears,  assuming  that  the  Ada 
I  ounce  code  of  HUMAN  has  been  written  fat  a  completely 
jorublc  manner.  The  complete  analysis  will  include  the 
Halstead  and  McCabe  analysis  of  all  of  the  Ada  source 
code  files  fat  the  repository.  This  will  provide  a  bench¬ 
mark  for  analysis  of  programmer  style,  as  well  as  being  a 
starting  point  for  other  'software  quality'  metrics. 

The  future  metrics  analysis  work  will  include  meas¬ 
urements  of  other  factors  such  as  lists  of  possible  execu¬ 
tion  path*,  deadlock  determination  for  programs  with  task¬ 
ing,  development  of  useful  metrics  foe  estimating  rcumbil- 
fay  and  portability  of  packages.  We  expect  to  Incorporate 
this  work  into  a  project  which  wiU  provide  an  analysis  of 
the  code  at  the  time  of  parsing  into  separate  tokens  since 
our  experience  with  ocher  metrics  analysis  programs  indi¬ 
cates  that  storing  such  information  at  one  time  and  making 
several  passes  through  the  list  of  tokens  will  make  the 
determination  of  these  additional  metrics  foe  portability, 
reusability,  path  analysis,  potential  deadlock,  etc.  much 
easier.  Results  obtained  will  be  easily  rrpiicaubic  since 
the  Ada  Repository  is  easily  available  and  does  not  consist 
only  of  proprietary  information. 
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Abitrsct 

Based  on  the  concept  of  Corraspondent  Computing,  wa 
propose  ’Sequential  Corraspondent  Operations*  as  a  strategy 
for  tha  sequential  implemtntallon  of  software  fault  tolerance, 
providing  redundancy  through  tha  use  of  correspondent 
operations.  Error  detection  and  forward  error  recovery  are 
performed  by  the  use  of  «  Comparative  lest.  The  Inherent 
high-level  programming  facilities  provided  by  Ada,  make  It 
the  language  of  choice  (or  Implementing  Sequential 
Correspondent  Operations.  This  sequential  scheme  Is  the  most 
natural  approach  for  systems  with  limited  hardware 
resources.  The  use  of  Ada  enhances  the  power  of  Sequential 
Correspondent  Operations,  making  It  an  effective  an  feasible 
strategy  for  developing  fault  tolerant  software. 


lJUIflQflUfillQJl 

As  computers  have  grown  more  complex,  not  only  In 
their  Internal  structure,  but  also  In  their  applications,  the 
need  to  ensure  reliability  has  Increased.  In  fact  computers  are 
Increasingly  being  used  In  critical  application  areas  where 
loss  of  computing  power  for  even  r.  few  seconds  can  be 
disastrous.  To  ensure  the  proper  functioning  of  the  computer 
system  even  In  the  face  ol  faults  has  become  a  challenge. 

There  are  two  omplementary  approaches  to 
constructing  highly  reliable  systems.  The  lirst  Is  fault 
prevention,  which  tries  to  onsure  that  tha  Implemented  system 
will  not  contain  faults.  This  can  be  achieved  by  using 
structured  design  methodologies,  quality  control  etc  to  avoid 
Introducing  fautts  In  the  system.  Testing  and  other  vacation 
techniques  are  also  used  to  find  and  remove  errors.  But  as  the 
complexity  of  tho  system  increases,  rosidual  faults  exist 
despite  extensive  application  of  fault  prevention  techniques.  To 
overcome  these  residual  design  Inadequacies  or  fautts,  fault 
tolerant  techniques  are  applied  to  ensure  the  reliability  ol  the 
system. 

Fault  totorance  may  be  dofinud  as  the  ability  to  doted 
and  recover  from  residual  design  Inadequacies  (errors) 
without  any  appreciable  loss  In  either  computation  or  time. 
There  are  a  number  of  fault  tolerant  strategies  available  for 
Implementing  reliable  systems,  prominent  among  which  are 
the  Recovery  Block  Scheme  (7)  and  tho  N-Vorsion 
Programming  (2j.  Recently,  tho  authors  have  proposed  u  lault 
tolerant  strategy  based  on  the  power  of  Correspondent 
Computing  [6]. 

This  paper  discusses  the  sequential  aspects  of 
Correspondent  Computing.  In  section  2,  we  present  a  brief 
background  of  the  concepts  of  Correspondent  Computing, 
Induding  its  error  detection  mechanism  tho  Comparative  tost. 
Section  3  presents  a  sequential  strategy  'Sequential 
Correspondent  Operations*  based  on  Correspondent  Computing 


for  Imptemantlng  fault  tolerant  software.  An  Ada 
Imptamantation  of  Saquantlal  Corraspondent  Operations  Is 
shown  In  section  4  Finally.  In  section  3  we  conclude  the 
discussion  and  give  directions  for  future  research. 

2-  CORRESPONDENT.  COMPUTING 

Correspondent  Computing  (5,6)  is  based  on  the 
philosophy  of  correspondence  which  can  be  staled  as  :  *lf 
executing  an  operation  can  produce  a  significant  effect,  then 
another  equally  significant  effect  can  be  generated  by  another 
semantically  correspondent  operation*.  Correspondence  is  the 
property  that  binds  two  operations  together.  The  relationship 
(between  the  two  operations)  being  redprocal,  equivalent  ot 
analogous.  If  a  cSstinct  and  predse  relationship  exists  between 
two  operations,  and  the  results  for  effects)  of  these  two 
operations  also  exhibit  this  same  precise  and  distinct 
relationship,  then  these  two  operations  have  a  correspondence 
relationship.  Operations  having  a  correspondence  relationship 
are  termed  as  Correspondent  operations. 

lot  us  illustrate  tho  concept  of  Correspondent 
Operations  with  an  example.  Consider  an  object  "A*  resting  on 
the  ground,  it  Is  now  exerting  a  force  on  the  ground  equal  to  Its 
weight,  let  this  be  Wt.  To  maintain  equilibrium,  the  ground  Is 
exerting  an  equal  and  opposite  reaction  R1.  Now  tel  us  place 
anothor  object  *B*  on  the  ground  exerting  a  force  equal  to  Its 
weight  W2,  and  the  reaction  from  the  ground  being  R2.  Since 
both  objects  are  In  equilibrium,  the  weights  are  equal  to  the 
reactions,  l.e.  Wt  «  Rt  and  W2  -  R2.  In  addition,  observe  that 
there  exists  a  precise  and  distinct  relationship  batween 
weights  of  the  two  objects  (Wt  and  W2)  and  this  same 
relationship  also  defines  the  reactions  (R1  and  R2),  l.e. 
(W1/W2)  -  (R1/R2)  -  constant.  Thus  the  two  objects  aro 
correspondent  with  one  another.  Using  tho  same  analogy,  two 
operations  are  correspondent  operations  if  tho  oporations  and 
the  results  (of  tho  two  oporations)  demonstrate  tho  samo 
relationship. 

A  program  Is  structured  Into  units  (modulos,  functions 
etc.),  and  each  of  which  can  bo  regarded  as  an  operation.  An 
operation  consists  of  sequences  of  smallor  oporations,  the 
smallest  being  the  single  Instruction.  Tho  operation  whose 
effect  *s  tho  target  of  correspondent  computing  Is  called  'Jio 
primary  operation.  Tho  primary  operation  can  bo  thought  of  as 
an  operation  whose  correct  execution  Is  more  critical  than 
other  constituent  program  oporations,  and  honce  Is  the  basis 
for  Ihe  creation  of  redundant  operations.  In  a  non-redundant 
environment  a  program  consists  of  only  primary  operations. 
Operations  which  generate  effects  that  correspond  to  tho 
primary  operation  are  called  correspondent  oporations.  The 
effects  of  a  correspondent  operation  may  bo  equivalent, 
complementary,  contradictory,  or  competing  to  the  effects  of 
the  primary  operation.  Correspondent  operations  can  be 
categorized  as  Reciprocal,  Duplicate,  or  Rosidual.  Reciprocal 
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operations  at*  semantically  the  Invorse  ol  the  primary 
operation.  Duplicate  operations  are  those  whose  behavior  Is 
semantically  equivalent  to  the  primary  operation.  Residual 
operations  arr  thoso  that  exhibit  correspondence 
relationships,  but  aro  neither  exactly  duplicate,  nor 
reciprocal  operations. 

All  fault  tolerance  must  be  based  on  the  provision  ol 
useful  redundancy,  both  for  error  detection  and  error 
recovery.  In  software  the  redundancy  required  Is  not  a  simple 
replication  of  programs  but  redundancy  of  design  (7]. 
Correspondent  computing  provides  the  requisite  redundancy 
through  the  use  of  correspondent  operations  lor  oach  primary 
operation.  In  addition  to  p’ovfdtng  useful  redundancy,  these 
correspondent  operations  are  also  powerful  enough  to  assist  In 
error  detection  and  error 
recoveiy. 

Error  detection  Is  accomplished  by  the  use  of  a 
Comparative  Test.  The  specifications  of  the  Comparative  test 
are  based  on  the  precise,  predefined  and  distinct  relationship 
of  the  primary  and  its  correspondent  operations.  As  has  been 
already  stated,  lor  operations  to  be  considered  ‘correspondent 
operations*  they  must  exhibit  the  same  relationship  for  the 
effects,  as  for  the  operations.  That  Is,  if  two  correspondent 
operations  produce  two  effects  (results)  then  these  results 
must  have  the  same  relationship  as  the  operations.  The  only 
possible  circumstance  in  which  the  relationship  ol  the  two 
results  differ,  Is  an  error  occurring  during  execution  of  one  ol 
the  operations,  thereby  changing  tha  result  of  one  of  the 
operations  from  the  desired  result.  The  Comparative  test  Is 
based  on  this  principle,  and  performs  error  detection  by 
observing  if  tha  relationship  of  the  results  differ  from  the 
predefined  relationship  of  the  two  correspondent  operations. 
For  example,  to  check  the  results  of  a  sorting  operation,  a 
Comparative  test  can  be  used.  The  comparative  lest  works  by 
comparing  tha  results  ol  the  primary  sort  operation,  and  the 
residual  soil  operation,  a  simple  match  procedure  described 
below  can  detect  if  errors  havo  occurred. 

fort  In  1..ARRAY.SIZE  loop 

If  P(l)  /*-  A  (RE(I)J  then 

MATCH  >  FALSE : 

end  If : 

end  loop; 

This  simple  procedure  Is  powerful  enough  to  doted  any 
data  Inconsistency  errors  as  well  as  computation  errors  that 
might  have  occurred  In  either  the  primary  or  the  residual 
operation. 

The  error  detection  component  Is  Incomplete  without 
some  form  ol  error  recovery  to  achlcvo  fault  tolerance. 
Correspondent  computing  provides  a  forward  orror  recovery 
strategy,  avoiding  the  high  tlme*space  overhead  In 
maintaining  mechanisms  for  rolling  back  tho  system  state  to 
an  error  freo  state.  Again,  tho  redundant  correspondent 
operations  provide  the  requisite  component  for  error 
recovery.  When  the  comparative  test  detects  an  error,  the 
erroneous  result  Is  masked  and  another  correspondent 
operation  Is  initiated,  and  on  termination  Its  results  tested 
with  the  results  of  the  previously  executed  operations.  This 
ensures,  that  the  correct  result  is  always  obtainod. 

In  the  next  section,  we  shall  discuss  in  detail  the  sequential 
aspects  of  Correspondent  Computing. 

3,.  SEQUENTIAL  CORRESPONDENT  OPERATIONS 

The  use  of  Correspondent  Computing  for  fault  tolerant 
systems  Is  based  on  the  redundancy  provided  by  the 
correspondent  operations.  These  correspondent  operations  are 
not  only  simple  to  formulate,  but,  are  also  powerful  enough  to 


assist  in  error  detection  and  error  recovery.  We  present 
‘Sequential  Correspondent  Operations'  as  a  strategy  for 
implementing  fault  tolerant  sottware.  This  sequential  scheme 
Is  the  most  natural  approach  (or  systems  with  limited 
hardware  resources. 

A  program  consists  of  a  sequence  of  operations,  and 
thoso  operations  consisting  of  sequences  ol  smaller  operations. 
In  a  fault  tolerant  environment,  It  Is  necessary  to  provide  for 
error  checking,  but  obviously  error  chucking  for  each  basic 
operation  Is  too  expensive,  In  terms  of  both  time  and  space 
complexity  to  perform.  From  the  viewpoint  of  software  fault 
tolerance,  tne  correct  behavior  of  soma  operations  Is  more 
critical  than  others.  Therefore,  It  Is  sulficlen!  to  provide 
redundancy  for  these  critical  operations,  rather  than  for 
evory  basic  operation.  Keeping  this  objective  In  mind,  we 
assume  that  a  program  consists  of  two  types  of  operations, 
critical  operations  requiring  redundant  components,  and  non* 
critical  operations.  These  critical  operations  having  error 
detection  and  recovery  capabilities  will  be  formed  using 
Sequential  Correspondent  Operations. 

A  fault  tolerant  program,  similar  to  any  other 
program,  Is  composed  of  a  number  of  sub-program  units,  such 
as  modules,  procedures,  functions  etc.  Using  Sequential 
correspondent  operations,  a  program  Is  composed  of 
conventional  (non*redundanl)  units,  and  sequential 
correspondent  operations.  These  units  are  again  composed  of  a 
number  of  conventional  and  redundant  sub-units.  Simply  put, 
a  program  contains  a  number  of  nested  non*redundant 
(conventional),  and  redundant  (sequential  correspondent 
operations)  units. 

3i.1  „ Structure  of  Sequential  Correspondent 
QatiaUttfl 

Sequential  Correspondent  operations  (SCO)  consist  of 
threo  components,  1)  entry  condition  :  it  Is  the  Initiation  of 
tho  sequential  correspondent  operation,  2)  the  processing 
component  ;  consisting  of  the  primary,  Its  correspondent 
operations  and  the  comparative  test,  and  3)  the  exit  condition  : 
the  termination  condition  where  the  results  are  returned  to 
the  calling  module.  The  structure  of  a  SCO  Is  shown  In  figure  1. 

A  sequential  correspondent  operation  Is  Initiated  when 
the  preceding  module  completes,  and  passes  control  to  the 
entry  condition  of  the  sequential  correspondent  operation.  The 
execution  sequence  Is ; 

1 )  Execution  of  the  primary  operation. 

2 )  Execution  of  the  first  correspondent  operation. 

3 )  The  results  ol  the  primary  and  correspondent  operation 
are  sent  to  the  comparative  test,  to  decide  If  the  results 
match. 

4 )  If  the  results  match,  the  sequential  correspondent 
operation  terminates. 

5)  If  the  rosuUs  fail  to  match,  the  next  correspondent 
operation  Is  executed.  This  new  result,  along  with  tha 
results  of  the  primary  and  the  previous  correspondent 
operations  Is  sent  to  the  comparative  test,  to  determine 
If  a  match  has  occurred.  Stop  5  is  repeated  until  a 
match  occurs,  or  all  correspondent  operation  are 
terminated. 

The  use  of  entry  and  exit  conditions  enables  easy 
expansion  of  the  system.  For  example,  at  a  later  stage,  a 
conventional  component  can  be  replaced  with  a  non-redundant 
component  without  any  Interfacing  problems. 
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3.2  Error  Detection  »nd_Error -Recount 

A  sequential  correspondent  operation  consists  ol  a 
primary,  ont  or  more  correspondent  operations,  and  a 
comparative  tost.  Tho  execution  ol  tho  sequential 
correspondent  operations  begins  with  tho  prlmrtv  operation 
being  Initiated.  Alter  the  primary  operation  completes 
execution,  one  ol  the  correspondent  operations  Is  executed 
noxt.  On  completion  ol  the  first  correspondent  operation  {Cl} 
tho  comparative  tost  Is  Initiated.  Tho  comparative  tost 
determines  II  the  results  ol  the  primary  and  tho  tlrst 
correspondent  operations  match.  II  a  match  is  obtained,  that  is, 
no  error  has  boon  dotocted,  tho  result  ol  the  primary  (or  tho 
correspondent)  operation  is  returned  to  tho  catling  modulo. 

When  a  match  (alts,  that  Is  an  error  stato  Is  dotocted  In 
tho  rosult,  anothor  correspondent  operation  (C2)  Is  Initiated. 
On  completion  ol  this  correspondent  operation,  tho 
comparative  tost  is  again  invoked.  Tho  comparative  tost  now 
compares  the  rosult  ol  tho  second  correspondent  operation 
(C2),  with  tho  rosults  ol  tho  primary  and  tho  first 
correspondent  operation  (Cl).  II  a  match  occurs,  tho 
comparative  test  selects  the  correct  rosult  (Irom  the  two 
results  that  match)  and  returns  control  to  tho  calling  routine. 
II  no  match  occurs,  another  correspondent  operation  (C3)  Is 
initiated,  and  on  completion  its  rosult  is  used  by  tho 
comparative  test  to  dotormino  if  the  correct  result  can  be 
obtained.  This  process  Is  repeated  until  either  tho  correct 
result  Is  obtainod,  or  all  tho  correspondent  operations  are 
completed. 


Whon  none  ol  the  primary,  or  tho  correspondent 
operations  In  a  sequential  correspondent  operation  match,  that 
Is.  tho  complete  unit  (ails,  anothor  sequential  correspondent 
unit  (operation)  might  bo  Invoked.  In  a  nostod  sequential 
correspondent  operation,  consisting  ol  a  primary  and  one  or 
more  correspondent  operations,  each  ol  which  (primary  and 
correspondent  operation)  Is  a  sequential  correspondent 
operation.  Tho  (allure  ol  a  lower  lovel  sequential 
correspondent  operation,  (which  might  be  the  primary 
operation  ol  the  higher  level  unit)  the  higher  level  sequential 
correspondent  operation  would  Invoke  anothor  lower  level 
sequential  correspondent  operation  (one  ol  the  correspondent 
operations  ol  tho  higher  level  Sequential  correspondent 
cporatlon),  repeating  tho  process  until  the  correei  result  Is 
obtained.  The  number  ol  redundant  units,  and  the  number  ot 
correspondent  operations  per  unit,  lor  each  primary  operation 
depend  on  the  criticality  ol  the  primary  operation.  Obviously, 
a  htghly  critical  operation  would  require  a  significantly 
higher  degree  ot  redundancy,  than  a  non-critical  operation. 

The  comparative  test  not  only  detects  errors,  but  also 
assists  In  error  recovery.  This  error  recovery  consists  ol 
ensuring  the  correct  result  Is  passed  to  the  catling  modulo. 
When  the  comparative  test  receives  the  result  Irom  tho 
primary  and  tho  correspondent  operations,  it  makes  a  decision 
on  whether  the  result  Is  correct.  At  this  point,  a  correct  result 
is  determined  II  any  two  results  match.  Whenever,  the  correct 
result  Is  not  obtained  Irom  the  primary  operation,  it  needs  to 
be  converted  to  the  primary  rosult  before  being  returned  to 
tho  calling  routino.  This  problem  can  be  solved  by  using 
‘reverse  correspondent  operations*.  Reverse  correspondent 
operations  are  operations  that  convert  the  result  ol  a 
correspondent  operation  to  an  ‘equivalent  primary  result*. 
For  example,  II  the  primary  operation  Is  to  sum  an  array  ol 
integers,  an  its  result  is  equal  to  too.  Its  reciprocal 
correspondent  operation  is  to  subtract  tho  array  elements 
(Instead  of  adding),  giving  a  result  equal  to  >100,  then 
equivalent  primary  result  lor  the  reciprocal  operation  can  be 
obtained  by  negating  the  reciprocal  result. 

The  use  ol  reverse  correspondent  operations,  and 
equivalent  correspondent  operations  make  the  design, 
implementation  and  execution  ol  the  comparative  test  easier. 
In  addition,  tho  rosult  Irom  the  correspondent  operations  does 
not  need  to  be  converted  by  the  comparative  test.  However, 
(hero  Is  a  slight  drawback  with  this  scheme,  the  reverse 
corrospondont  operations  require  additional  execution  time, 
which  might  slow  down  the  entiro  sequential  correspondent 
operation. 

Tho  use  ol  sequential  corrospondont  operations 
onhanccs  the  case  ol  implementation  ol  a  lault  tolorant 
program.  In  (ho  next  section  wo  will  give  an  Ada 
imptomontation  ol  sequential  correspondent  operations  lor 
fault  tolerant  applications. 

a,  ADA  IMPLEMENTATIQN_QF_SEQU£NI1A1. 

CORRESPONDENT  OPERATIONS 

Sequential  Correspondent  Operations  Is  an  ollcctivo 
strategy  for  implementing  fault  tolorant  software,  providing 
rodundsney  through  tho  use  ol  correspondent  operations.  Ada, 
the  new  genoral  purpose  programming  language,  is  based  on 
tho  definitions  proposed  by  tho  U.S.  Department  ol  Defense  for 
uso  In  embedded  systems.  It  Is  tho  culmination  ol  a  decade  ol 
specification  and  revision  of  successive  vorsions  of  the 
language,  and  rcllocts  tho  current  trends  towards  data 
abstraction,  multi  tasking,  generics,  oxcoptlon  handling, 
roadability,  reliability,  otc.  Ada  is  a  powerful,  yet  expressive 
and  feature  rich  language,  which  addrosses  a  wide  range  of 
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application  areas.  It  it  a  tool  that  encourages  good  software 
engineering  principles,  having  features  to  detect  mora  errors 
tarty  »nd  automatically,  helping  programmers  to  writs  good 
programs,  without  inhibiting  creative, ess  and  Ingenuity.  The 
use  ot  Ada  enhances  the  power  ol  Sequential  correspondent 
operations,  making  Its  development  snd  Implementation 
easier,  (aster  and  more  efficient. 

A  fault  tolerant  program  consists  of  number  ot  nested 
tevefs,  each  level  containing  both  redundant  and  non-redundant 
modules.  In  Sequential  Correspondent  operations,  a  program 
comprises  of  a  number  of  nested  conventional  and  redundant 
(sequential  correspondent  operations)  modules.  An  Ada 
Implementation  of  such  a  program  could  be  written  as  : 


procedure  MAIN  Is 

procedure  C0NVENT10NALJ.100UIEJ  Is 

procedure  SEOUENlTA^CORRESPONDENT.OPERATtON.l  Is 

e 

procedure  SEOUENTtAL.CORRESPONDENT.OPERATtON  J  Is 
procedure  CONVENTIONAL.MODUIEJ  1$ 


procedure  CONVENTIONAL_MOOUIE_N  fs 

procedure  SEOUENTtAl_CORRESPONOENr_OP£RATION.N  is 
■ 

a 

begin  ••  procedure  MAIN 


end  MAIN ; 

The  above  example  shows  tho  skeleton  of  a  fault 
tolerant  program  using  sequential  correspondent  operations. 
Of  course,  each  ot  the  conventional  modules  and  the  Sequential 
correspondent  operations  (modules)  can  bo  further  nested, 
each  comprising  of  both  conventional  modules  and  sequential 
correspondent  operations.  Considering  only  the  sequential 
correspondent  operation  at  tho  lowest  tovel,  that  is,  there  are 
no  more  nested  redundant  modules  Inside  this  sequential 
correspondent  operation.  The  structure  of  such  a  sequential 
correspondent  operation  could  bo  implemented  as 

procedure  SEOUENTIAL.CORRESPONDENT.OPERATIONJ  is 
••  local  variables 

procedure  SEO.CORR.OPERATiONJ.PRiMARY  is 
begin 


end  SEQ.CORR.OPERATION J.PRtMARY ; 

procedure  SEQ_CORR_OPERATION  .(.RECIPROCAL  is 
begin 


procedure  SEO.CORR.OPERATION  J.DUPUCATE  is 
begin 


end  SEQ.CORR.OPERATION  J.DUPUCATE ; 

••  other  correspondent  operations  (as  needed) 


begin  -  SEQUENT  tAL.CQRRESPONOENT.OPcRATl  ON  J 
SEO.CORR.OPERATION,I.PR!MARY(  DATA)  t 
SEO_CORR.OPERATtONJ,R£C!PROCAL(OATA) ; 
COMPARATIVEJEST; 

If  not  (MATCH)  then 

SEQ.CORR.OPERATION J.DUPUCATE  (DATA) ; 


end  it ; 

end  SEQUENT  tAL.CQRRESPOND£NT.OPERATlONJ : 

The  sequential  correspondent  operation  shown  above 
consists  of  a  primary,  n  (  >«  t)  correspondent  operations  and 
a  comparative  test.  Execution  starts  when  control  Is  passed  to 
the  sequential  correspondent  operation  SEQUENTIAL.* 
CORRESPONDENT  .OPERATION.!,  First,  the  primary  operation 
(m  this  case  SEQ.CORR.OPERATION. I. PRIMARY)  is  executed. 
Next  one  ol  the  correspondent  operations  is  initiated.  On 
complet'on  of  the  first  correspondent  operation  (SEO_* 
CORR.OPERATIONJ.RECIPROCAL).  the  Comparative  test  Is 
suited.  The  comparative  test,  obtains  the  results  from  the  two 
completed  operations,  and  checks  if  the  (wo  results  match.  II 
the  match  occurs,  then  the  results  are  correct.  When  a  correct 
result  Is  obtained,  the  results  are  passed  to  the  catting 
routine,  and  the  sequential  correspondent  operation 
terminates.  However,  if  a  match  has  not  occurred,  then 
another  correspondent  operation  is  initiated,  tho  process  being 
repoated  until  the  correct  results  are  obtained,  or  all 
correspondent  operation  are  completed. 

Using  this  basic  structure,  let  us  elaborate  tho  power 
of  sequential  correspondent  operation  with  an  example.  The 
example  consists  of  a  fault  tolerant  sorting  of  an  array  ot 
integers.  This  simple  program  consists  ol  reading  the  array  ot 
integers,  sorting  this  array  In  an  ascending  order,  and 
printing  the  result  ot  the  sorted  array.  In  this  problem,  the 
sort  routine  is  critical  and  therefore  requires  redundancy. 
Hence,  tho  sort  will  be  fault  tolerant,  and  implemented  using 
Sequential  Correspondent  Operations.  To  simplify  the  coding 
and  to  improve  readability  the  implementation  details  will  be 
ignored. 

procedure  SORT.MA1N  is 

procedure  READ.ARRAY  (ORIG.  ARRAY :  out  ARRAY.TYPE )  Is 
begin 


end  READ.ARRAY; 


procedure  SEO  CORR.SORT  (ORIG.ARRAY ;  in  ARRAY.TYPE ; 

RESULT :  out  ARRAY.TYPE )  is 


begin 


end  SEQ.CORR, OPERATION .I.RECIPROCAL ; 


end  SEQ.CORR.SORT ; 
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procedure  PR1NT.ARRAY  (RESULT  ARRAY  TYPE  \  Is 
begin 


end  PRINT_ARRAY ; 

begin  -  SORTJUAIN 
READ. ARRAY  (OR  ARRAY): 

SEQLCORR.SORT  (OR.ARRAY,  RESULT_ARRAY) ; 

print_array  (result.array)  : 
end  SORT.MAIN: 

Since  the  reeding  and  printing  ara  conventional 
modulas,  wt  will  not  ba  showing  their  Implementation.  The 
sequential  correspondent  operation  SEO.CORR  SORT  Is 
described  next. 

proceAxe  SEO_CORR_SORT  { ORK3.ARRAY :  ki  ARRAY  TYPE ; 

RESULT :  out  ARRAYJTYPE )  Is 
••  local  variable  declarations 
••  primary  and  correspondent  sorting  procedures 
procedure PRIMARY.SORT { O.ARRAY •.{» ARRAY  TYPE : 

P,ARRAY  :out  ARRAY 'TYPE)  Is 

begin 


(or  J  In  1..ARRAY.SIZE  loop 
II  RESJN  (J)  /«  TEMP(J)  then 
MATCH  >  FALSE: 

end  It: 

end  loop  -  (or  J 
K  MATCH  then 
RESULT:- RESJN: 
end  It ; 
end  loop 

erdCOMPARATIVE_iEST: 
begin  -  SEQ.CORR.SORT 
PRtMARY.SORT  (ORIG.ARRAY.  P.ARR) ; 
RESULT.UST  (UST.SIZE) P.ARR); 
RECIPROCAL.SORT  (ORK3,  ARRAY.  R.ARR); 
COMPARATIVEJEST  (R.ARR.  RESULT.  UST, 
LtST.SIZE,  MATCH): 

II  not  (MATCH)  then 

LIST..SIZE  UST.SIZE  ♦  t  : 

RESULT.LIST  (UST.SIZE) R.ARR  ; 
DUPUCATE.SORT  (ORIG.ARRAY,  D.ARR) : 
COMPARATtVE_TEST  (D.ARR.  RESULTJJST. 

UST.SIZE,  MATCH) ; 

It  not  (MATCH)  then 


••  primary  rotting 
end  PRtMARY.SORT ; 


-  other  correspondent  operations 
end  If : 
end  It : 

end  SEO.CORR.SORT : 


procedure  RECIPROCAl^SORT  ( O.ARRAV  in  ARRAY  TYPE ; 

R_ ARRAY :  out  ARRAY  TYPE)  Is 

begin 


••  reciprocal  sorting 

••  convert  results  to  equivalent  primary  result 
••  using  reverse  correspondent  operations 

end  RECIPROCAl^SORT ; 


prcoeAxe  OUPUCATE.SORT  (0.  ARRAY :  in  ARRA  Y  TYPE ; 

O.ARRAY :  out  ARRAY  TYPE )  Is 

begin 


■ 

-  duplicate  sorting 
end  DUPUCATE.SORT ; 


procedure  RESIDUAL.SORT  (O  ARRAY :  In  ARRAY  TYPE ; 

RE.ARRAY :  out  ARRAY  TYPE")  Is 

begin 

••  residual  sort 

••  convert  results  to  equivalent  primary  result 
••  using  reverse  correspondent  operations 

end  RESIDUAL.SORT ; 

*•  other  correspondent  operations  It  desired 


procedure  COMPARATIVEJTEST  (RESJN :  In  ARRAY  TYPE : 

RES.UST :  In  UST  TYPE; 

SIZE:  in  INTEGER: 

MATCH:  In  out  BOOLEAN)  Is 

begin 


MATCH  >  FALSE: 
for  I  In  1..SIZE  loop 
MATCH  >  TRUE: 

TEMP  >  RES.LIST  (I) ; 


Any  sorting  atgoriihm  can  be  used  as  the  primary  sod 
algorithm.  Using  this  primary  sort  algorithm,  Its 
correspondent  operations  are  Implemented  using  the 
correspondent  relationships,  such  as  duplicate,  reciprocal  and 
residua).  In  this  example,  we  ara  converting  the  results  ol  the 
correspondent  operations  to  an  equivalent  primary  result,  so 
that  the  comparative  test  becomes  easier.  The  results  from  the 
primary  and  the  correspondent  operations  are  stored  In  a  list 
(RESULT. LIST).  The  comparative  test  then  compares  the 
results  In  the  RESULT.UST  with  the  new  result  obtained.  In 
this  way  each  result  can  be  compared  with  every  other  result. 
When  a  match  Is  obtained,  the  resuit  Is  taken  as  the  correct 
result  and  returned  to  the  catting  routine,  which  In  this 
program  Is  procedure  SORT.MAIN. 

3,. CONCLUSION 

This  paper  presents  a  fault  tolerant  strategy  based  on 
Correspondent  Computing.  The  strategy  Sequential 
Correspondent  Operations  consists  ol  a  primary,  *n*  (>  -  1) 
redundant  correspondent  operations,  and  a  comparative  tosl. 
These  correspondent  operations  not  only  provide  the  desired 
redundancy  (or  fault  tolerant  applications,  but  ere  also 
powtrful  enough  to  assist  In  error  detection  and  error 
recovery. 

In  this  scheme,  a  set  of  primary  and  corrtspondent 
operations  (SCO)  ara  executed  sequentially.  In  each  SCO,  first 
the  primary  and  one  correspondent  operation  are  executed  and 
their  results  passed  to  the  comparative  test.  The  comparative 
test  perlorms  error  detection  by  comparing  the  results  ol  the 
two  operations.  II  the  results  match,  that  Is.  no  error  has 
occurred,  the  resutt  1$  passed  as  the  correct  result.  However, 
II  an  error  has  occurred,  then  another  correspondent 
operation  Is  Initiated,  and  Its  result  passed  to  the  comparative 
lest.  The  comparative  lest  now  compares  this  result  with  the 
two  previous  results,  to  determine  II  an  error  has  occurred. 
This  process  continues  unlit  either  the  correct  result  Is 
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obtained,  or  a9  correspondent  operationc  are  completed. 

This  sequential  schema  is  tho  most  natural  approach 
lor  systems  with  limited  hardware  resources.  The  use  ol  Ada, 
with  Its  Inherent  high-level  programming  facilities,  mako  it 
an  etogant,  elfective  and  feasible  strategy  for  development  and 
Implementation  of  fault  tolerant  software. 
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The  Ada  Binding  for  POSIX 
David  Emery  Terry  Fong 
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Abstract 

The  Technical  Committee  on  Opeating  Systems  of  the  IEEE  Computer  Society  sponsors  to  Pi 003  Com¬ 
mittee's  efforts  on  the  Portage  Operating  System  Interface  for  Computer  Environments  (POSIX).  The 
PI003.5  Wording  Group  was  termed  in  1987  to  develop  a  POSIX  Ada  interface.  This  report  provides  to  ra* 
Itenalt  tor  to  binding,  details  specific  problems  encountered  and  their  sotutfcn,  and  outSces  fie  status  of  the 
effort. 


IrtroduatontoPOSX 

There  is «  growing  convergence  toward  to  Unix  operating 
system  as  a  standard  ter  time- sharing  and  single-user 
computing  environments.  The  wide  variety  of  Unix-derived 
systems  —  espeoaiy  System  V  and  Berkeley  derivatives 
— has  made  the  promise  ci  a  standard  Unix  quite  elusive. 

The  IEEE  has  formed  a  committee  to  develop  a  Portable 
Operating  System  Interface  Standard  (POSIX).  The  work 
of  this  group,  IEEE  P1003,  has  grown  from  to  early  ef¬ 
forts  of  Aisr/group.  and  the  Influential  Standard  that  their 
technical  committee  proposed,  in  1985  to  two  groups 
merged,  and  immediately  formed  a  working  group  — 
PJ003.1  —  to  define  a  programming  language  interface  for 
to  proposed  standard. 

‘The  goal  of  to  P1003.1  Working  Group  was  lo  promote 
portability  of  application  programs  across  Unix  environ¬ 
ments  by  developing  a  dear,  consistent  and  unambiguous 
standard  ter  to  interface  specification  of  a  portable  oper¬ 
ating  system  based  on  tf  e  Unix  system  documentation.* 1 

At  to  time  of  this  writing  to  POSIX  interface  specifica¬ 
tion  is  in  balot.  K  was  not  unti  mkf-1287  tot  to  P1003.5 
committee  was  termed  2,  charged  with  specifying  an  Ada 
binding  for  to  ton-proposed  dart  12  version  of  to  POSIX 
interface  specification.  Several  other  working  groups  have 
been  termed  to  deal  with  other  pressing  requirements,  such 
as  real-time,  and  security. 


In  to  next  section,  a  brief  overview  of  to  barriers  to  a 
POSIX  Ada  is  presented..  Wowed  by  a  short  rationale  of 
to  group's  approach.  A  short  summary  and  status  report 
can  be  found  at  to  end. 

Berrien  to  Ada  BWnjj 

The  Base  Specification 

The  basic  POSIX  document  consists  of  a  coSection  of  C 
function  declarations,  with  supporting  header  files  and  text 
to  explain  to  semantics  of  each  call.  Therefore,  to 
POSIX  interface  is  specified  with  C  semantics,  which  are 
not  to  same  as  Ada  semantics.  One  problem  with  C  is 
that  it  is  not  a  strongly  typed  language.  Many  Afferent 
POSIX  routines  have  Tnt*  parameters.  Ona  of  to  chal¬ 
lenges  of  doing  an  Ada  binding  Is  trying  to  determine,  for  a 
given  POSIX/C  int  parameter,  an  associated  Ada  type. 
This  is  particularly  true  for  flag  values,  which  map  most 
directly  to  Ada  enumeration  types. 

There  is  some  support  lor  modularity  in  the  C  interlace  via 
to  ‘header*  Hies.  These  lend  to  encapsulate  common 
type  declarations  and  constants  used  by  a  set  of  related  C 
(unctions.  However,  a  Mo-1  mapping  of  header  files  to 
Ada  packages  will  not  work,  because  many  ol  the 
POSIX/C  functions  require  more  ton  1  headf  file,  but  an 
Ada  operation  can  be  defined  in  only  1  package. 

IhaJrfJBias 

There  are  many  places  in  the  POSIX  definition  where  to 
POSIX/C  binding  refers  back  to  the  definition  of  to  C  Ian- 
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language.  Perhaps  the  most  notable  example  concerns 
memory  management.  There  Is  no  POSIX  routine  to  allo¬ 
cate  memory.  Instead,  memory  is  allocated  using  the  C 
maHocO  routine,  which  is  defined  by  the  appropriate  C 
standard  (ANSI  C,  in  this  case},  and  by  the  particular 
implementation  ol  C  used  for  a  specific  POSIX 
imptemertatioa 

Another  example  of  where  the  POSiX  definition  deters  to 
the  C  language  it  in  system  Smits.  POSIX  depends  on  the 
0  implementation  to  define  such  things  as  INT_MAX, 
INTJulIN  and  CIKJTCK.  These  correspond  to  3ys- 
iem.MaxJnt,  System.MinJn!  and  System.;**.  Since 
there  is  no  POSIX-defined  minimum  values  lor  these  num¬ 
bers  (such  definitions  are  in  the  C  Language  Standard}, 
the  POSIX  Ada  binding  can  make  no  particular  as¬ 
sumptions  about  system  Emits.  This  is  particularly  impor¬ 
tant  lor  CIKJTCK,  which  Is  really  a  function  of  the 
hardware  and  operaSog  system's  dock  resolution,  rather 
than  the  capabilities  ol  a  given  compiler. 

Salt  &n!!& 

There  are  several  Inherent  conflicts  between  C  ‘style*  and 
Ada  'style*.  C  defines  no  language  error  signalling  faclity, 
so  each  C  tunc  Son  has  its  own  way  ol  indicating  an  error. 
In  many  cases,  the  funcSon  returns  a  known  value  lor  an 
error  (such  as  an  address  ol  0),  and  another  value  for 
success.  This  is  very  hard  io  directly  map  to  Ada.  In¬ 
stead.  Ada  exceptions  should  be  used,  but  then  many  com¬ 
mon  Unix  coding  practices  that  cal  a  rout-'ne  and  branch  to 
an  error  handter  based  on  the  result,  would  have  no  tfrect 
Ada  analog. 

One  particular  C  coding  technique  used  often  in  the  POSIX 
C  specification  is  a  function  that  both  returns  a  value  as  a 
function  result  and  also  changes  one  ot  the  function's  pa¬ 
rameters.  The  direct  Ada  analog  is  a*  function  with  IN 
OUT  or  OUT  parameters,  which  is  not  allowed  in  Ada.  In 
many  cases,  the  single  C  operation  really  performs  several 
logically  distinct  (unctions,  and  the  mapping  from  this  func¬ 
tionality  to  Ada  is  not  always  obvious. 

Minimal  Interface  Definition 

Another  problem  with  the  POSIX  definition  is  that  POSIX  is 
a  minimal  interface  definition.  In  order  to  allow 
implementation  freedom  and  to  maintain  compatabilty  with 
several  existing  systems,  many  POSIX  calls  define  a 


minimum  set  of  services  or  data  elements.  For  instance, 
the  data  type  that  defines  a  directory  entry  contains  'at 
least  the  following  fields:  ...*.  Again,  this  tends  lo  conflict 
withlhe  Ada  strong  typing  model,  where  each  element  ol  a 
record  type  must  oe  known  at  compile  time.  Furthermore, 
there  Is  fce  issue  ot  name  conflicts  that  can  occur  when  an 
implementation -defined  field  on  some  system  has  the  same 
name  (visible  in  the  same  scope)  as  some  programmer-de¬ 
fined  name.  The  program  may  compile  without  error  on 
one  POSIX  Implementation,  but  wil  not  compile  on  another 
implementation. 

Part  ot  this  minimal  interface  consists  ol  a  set  ol  prede¬ 
fined  names  and  constants  that  define  s  specific  POSIX 
environment.  For  instance,  ihere  is  a  POSIX  constant 
names  PATH.MAX,  which  is  the  maximum  number  ol 
characters  (bytes)  in  a  pathname.  The  definition  in  Ada 
of  a  type  for  pathnames  (which  should  have  up  to 
.-aTH.MAX  characters)  is  not  obvious.  String  handfing  in 
general  is  a  non  trivial  problem,  because  ol  the  much  more 
dynamic  C  definition  ot  strings,  and  also  because  POSIX 
permits  8  bit  characters,  which  are  not  part  ol  the  Ada 
predefined  CHARACTER  type.  So,  what  type  should  the 
POSIX  operation  that  provides  tha  name  ol  the  current 
working  directory  (the  C  getcwd{)  function)?  Hew  do  you 
note  that  this  value  can  be  only  PATH_MAX  bytes  long, 
and  how  do  you  handle  the  case  where  some  value  in  the 
result  has  a  byte  value  >  127,  which  is  not  a  legal  value  ter 
an  element  in  the  Ada  predefined  STRING  type? 

lasKs.Kfsus.Pfocesscs 

Finally,  POSIX  system  calls  assume  a  single  thread  of 
control.  Since  an  Ada  program  can  contain  many  tasks 
(possibly  running  concurrently  on  a  multiprocessor  imple¬ 
mentation),  the  specific  effects  ol  concurrency  and  pre¬ 
emption  must  be  studied  ter  each  POSIX  interface.  Some 
services  present  no  problems,  but  others,  particularly 
those  that  maintain  local  state  such  as  I/O  services,  re¬ 
quire  some  sort  ol  redefinition  to  define  their  behavior  in  the 
(ace  of  multiple  threads  ol  execution. 

POSIX  Signals  are  the  worst  case  lor  an  Ada  binding 
supporting  tasking.  In  POSIX,  a  signal  is  an  asynchronous 
event,  and  the  user  can  associate  a  function  to  handle  the 
arrival  of  a  signal.  Some  signals  represent  Ada  excep¬ 
tional  conditions,  such  as  numeric  errors  or  attempts  to 
dereference  a  null  pointer.  Other  signals  represent  true 
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asynchronous  «vents,  such  as  the  completion  of  VO.  In  a 
muM-#i«adad  Ada  program,  should  a  signal  be  deSvered  to 
a  specific  task,  or  to  at  tasks?  How  can  a  task  or  task 
entry  or  subprogram  be  associated  with  a  given  POSIX 
signal?  An  Ada  binding  tor  POSIX  must  support  ail  o ( the 
POSIX  services,  induing  POSIX  signals.  Developing  the 
correct  model  (or  signals  wilt  be  the  hardest  part  of  the 
Adabirxfng. 

Rationale  tor  the  Ada  Binring 
Goal 

The  principal  goal  ol  the  working  group  is  to  create  a 
POSIX  Ada  binding  which  is  useful,  portable,  and  which 
exhibits  good  style.  POSIX  primitives  must  be  made 
available  to  Ada  programs  such  that  POSIX  Ada  applica¬ 
tions  can  be  specific  to  POSIX,  but  otherwise  portable 
across  machine  architectures  and  Ada  compilers. 

Level  of  Abstraction 

Three  possible  levels  of  abstraction  for  POSIX  Ada  have 
been  identified:  direct,  abstract,  and  independent.  A  direct 
binding  is  one  where  the  base,  C  operations  are  mapped  as 
closely  as  possible  into  Ada.  An  abstract  binding  defines 
POSIX  abstract  data  types  by  abstraction  from  the  ba^e 
definition,  and  then  partitions  these  abstract  types  and 
their  operations  into  logically  related  collections 3  An  inde¬ 
pendent  binding  goes  farther  in  the  abstraction  process: 
there  is  no  strict  one-to-one  relationship  between  POSiX  C 
and  Ada  operations. 

In  committee,  the  abstract  level  has  been  accepted  both  in 
principle  and  in  practice.  It  is  clear  that  POSIX  Ada  will 
comprise  a  set  of  Ada  components  which  represent  the 
functionality  of  POSIX,  organized  to  provide  good  Ada 
style  while  remaining  intelligible  to  a  knowledgeable  POSIX 
Cuser. 

Any  POSIX  C  function  will  be  subject  to  the  following  con¬ 
version  rules  when  being  mapped  to  POSIX  Ada: 

•  Functions  will  be  bundled  in  Ada  packages  as 
subprograms,  task  entries,  or  generic  units. 

•  Use  of  Ada  identifiers  will  lead  to  significantly 
more  expressive  names. 

•  Polymorphic  functions  will  often  be  decomposed 
into  a  family  of  overloaded  subprograms. 


•  Some  functions  may  be  omitted  where  inap¬ 
propriate  tor  Ada  (e.g.  mallocO). 

•  Error  states  wil  lead  to  termination  by  exception 
propagation,  rather  than  the  setting  of  a  return 
code. 

Easy  and  Hard  Mappings 

Some  aspects  of  the  binding  are  relatively  easy,  since 
there  appears  little  conflict  between  POSIX  C  functionality 
and  a  straight-forward  abstract  Ada  equivalent.  In  these 
cases  the  main  effort  is  choosing  identifiers,  parameter 
types,  and  error  handling  mechanisms.  Examples  include 
POSIX  I/O,  (Srectory,  and  system  database  primitives. 

Other  aspects  of  the  binding  are  not  as  amenable  to  this 
simple  transformational  approach;  in  particular,  difficulties 
arise  from  the  relationship  between  POSIX  processes, 
Ada  tasks  and  programs.  POSIX  signals  are  semantically 
difficult  for  a  number  of  reasons,  treated  in  the  previous 
section. 

It  should  be  noted  that  it  is  precisely  those  POSIX  opera¬ 
tions  which  are  the  easiest  to  map  into  Ada  which  are 
likely  to  be  the  most  useful.  A  majority  of  applications  will 
most  likely  rely  only  upon  the  ‘easier*  file  and  directory 
operations,  while  only  a  small  minority  wil  need  to  directly 
manipulate  signals. 

The  Basics:  Names.  Types,  and  Error  Handling 

A  surprisingly  general  agreement  has  been  reached  in  the 
areas  of  names,  types,  and  error  handling.  Expressive 
Ada  identifiers  will  be  used  in  place  of  cryptic  (if  not  mis- 
leadng)  C  identifiers  4.  Renaming  to  provide  C  equivalent 
names  has  been  proposed  by  some,  but  this  is  controver¬ 
sial. 

The  basic  POSIX  STRING  and  FILE.DESCRIPTOR  types 
— which  are  used  throughout  the  binding  —  have  received 
a  great  deal  of  the  group's  attention.  Since  the  Ada  char¬ 
acter  set  is  limited  to  7-bit  ASCII,  while  POSIX  requires 
both  8-bit  and  multi-byte  characters,  most  operations  will 
rely  upon  a  POSIX  STRING  type.  This  type  will  be  inter¬ 
convertible  with  respect  to  Ada  Standard  STRING5. 
FILE_DESCRIPTOR  will  be  either  an  explict  integer  type, 
or  a  private  type;  arguments  for  integer  type  are  based 
upon  the  need  to  index  arrays  by  FILE_DESCRIPTOR. 
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One  significant  departure  from  base  POSIX  Is  the  setting 
ol  Hags*  parameters  —  bit  strings  —  by  application  cl 
Ada  constructors  In  place  ol  bit  value  assignment 

Exceptions  are  the  basic  mechanism  lor  POSIX  Ada  ’error  6 
handing.'  Operations  which  encounter  an  exception  condi¬ 
tion  wil  raise  an  expressive  and  specific  exception,  rather 
than  returning  a  'strange  value.*  The  degree  to  which 
other  mechanisms  wil  be  supported  is  stll  unresolved:  there 
Is  some  agreement  on  a  'predcate*  style  lor  certain  sorts 
ol  POSIX  access. 

Cordusions  and  Status 

The  authors  beleive  that  the  development  ol  a  single, 
widely  used  operating  system  Interlace  in  Ada  will  have 
immense  benefits  lor  all  users  ol  the  language.  Ada  source 
code  reuse  has  not  proven  to  be  as  significant  as  hoped; 
one  major  barrier  may  be  the  lack  ol  a  common  substrate 
(or  reusable  Ada.  POSIX  Ada  can  be  such  a  foundation. 

The  POSIX  Ada  working  group  has  held  three  meetings, 
each  ol  two  or  three  days.  A  fourth  meeting  Is  planned  lor 
June  in  Houston,  sponsored  by  MITRE  Corporation,  with 
meetings  planned  with  NASA  representatives  and  con¬ 
tractors  6.  A  sixth  meeting  Is  scheduled  lor  October  1988, 
and  a  preliminary  draft  ol  a  POSIX  Ada  Interface  is 
planned  lor  early  1989. 


1  POSIX  Explored,  rusr/group,  Santa  Clara  California. 

2  Note  that  the  authors  are  olficers  ol  the  P1003.5  working 
gap: 

T.  Fong  (US  Army)  —  Chair 
S.  Boyd  (Meridian)  —  Co-Chair 
D.  Emery  (MITRE)  —  Secretary 
M.  Gart  (Alsys)  —  Rationale  Editor 

3  This  approach  is  quite  similar  to  that  described  by  H. 
Fisher,  in  his  'PCTE  Ada  Interface'  presentation,  APSE 
Builder's  Working  Group,  SIGAda  International  Conference, 
November  1987. 

4  Although  names  should  not  become  unwieldy. 


Any  issues  relative  to  ASCII.NUL  will  be  handled  by  the 
interface. 

NASA  Is  considering  POSIX  for  the  Space  Station  project 
host  and  target  architecture. 
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Dr.  H.  Susan  Rlchman  Dr.  Charles 

Penn  Scare  Harrisburg  Mississippi 


ABSTRACT 

College  and  university  (acuity  have  di((erent 
needs  and  expectations  (roa  a  prograaalng  language 
course  than  aost  other  audiences,  especially  when 
Ada  Is  che  language.  Specifically,  they  require  a 
grounding  In  software  cnglrecrtng,  adequate  tiae 
for  asalallatlon  of  the  concepts  involved,  and 
hands-on  experience  working  on  a  large  project. 
These  requlrcaents  are  not  act  by  the  typical 
college  course,  short  course,  or  self-study. 

The  Ada  Currlculua  Developacnc  Sealnsr  des¬ 
cribed  herein  aore  chan  act  Its  objective  of  pro¬ 
viding  participants  the  background  to  enable  effec¬ 
tive  Integration  of  Ada  Into  the  curricula  of  their 
hoae  Institutions. 

This  paper  discusses  che  design  of  che  pro- 
graa,  che  challenges  presented  by  the  participants' 
Individual  backgrounds,  and  che  special  techniques 
used  In  the  presentation  of  the  lnforaatlon. 
Details  of  the  laboratory  exercises  and  teaa  solu¬ 
tions  are  discussed  and  evaluated.  Participant 
reactions  are  assessed  and  Implications  for  future 
program  design  derived.  Ceneral  Information  for 
ocher  Institutions  contemplating  similar  programs 
is  Included. 


INTRODUCTION 

Program  Background 

The  Ada  Curriculum  Development  Seminar  held  at 
Tuakegee  University  from  June  S  through  July  1, 
1988  had  Its  roots  In  four  years  of  previous  simi¬ 
lar  programs.  These  programs  were  sponsored  by  che 
U.S.  Army  Center  for  Tactical  Computer  Systems 
(CENTACS)  and  were  held  at  Ft.  Monmouth,  New 
Jersey  during  Che  summers  of  1981,  1982,  and  1983, 
and  at  Tuskegce  in  1984.  The  objectives  of  all 
these  programs  were  Co  propagate  the  Ada  program¬ 
ming  language  Into  college  and  university  computer 
science  curricula  by  providing  an  Intensive  learn¬ 
ing  experience  for  faculty  members.  All  three  of 
the  professional  staff  of  this  Seminar  were  parti¬ 
cipants  In  one  of  the  previous  piograms. 

Seminar  Objective 

The  seminar  objective  as  stated  in  the  application 
brochure  was  "to  provide  comprehensive  experience 
in  Che  Ada  Programming  Language  to  college  and 
university  computer  science  faculty  so  that  they 
may,  in  turn,  effectively  teach  Ada  to  their 
students.  In  the  course  of  the  seminar,  the 


C.  Peterson  Hr.  Donald  C.  Fuhr 

State  Unlv.  Tuskegce  University 


expertise  and  experience  of  the  participants  will 
be  applied  to  curriculum  design  and  the  development 
of  materials  (or  use  In  courses  at  their  home 
institutions.  All  of  the  features  of  the  Ada 
Programming  Language  will  be  explored,  and 
extensive  hands-on  experience  wll  be  provided." 

The  seminar  goals  were: 

To  acquaint  the  participant  with  the  Ada  style 
of  program  development  and  software  engineer¬ 
ing  methodology. 

To  enable  the  participant  to  write  small-co- 
medlum  sized  Ada  modules  and  programs. 

To  Instill  a  working  knowledge  of  Ada's  more 
advanced  features  Including  exception  hand¬ 
ling,  generic  units,  and  tasking. 

To  acquaint  the  participant  with  Ada  coding 
style  conventions. 

To  teach  the  use  of  Ada's  oodularlty  features 
In  constructing  software  systems  from  reusable 
software  components. 

To  emphasize  the  importance  of  software  en¬ 
gineering  practices  through  the  experience  of 
modifying  code  written  by  other  participants 
and  through  programming  In  teams  on  larger 
projects. 


PLANNING  MODEL 

The  fundamental  premise  behind  our  planning 
for  this  Seminar  was  that  college  students  and, 
therefore,  college  faculty  need  a  different 
approach  to  the  Ada  programming  language  from  that 
which  Is  appropriate  for  working  programmers.  This 
premise  Is  based  on  the  following  observations: 

The  vast  majority  of  Ada  training  courses  for 
Industry  are  only  a  few  days  in  length,  and  do  not 
always  Include  hands-on  exercises.  Essentially  all 
the  information  must  be  presented  by  the  instruc¬ 
tor,  with  very  little  outside  reading  or  assimila¬ 
tion  time  for  the  students.  We  believe  that  this 
leads  to  shallow  learning  of  syntax  and  semantics, 
with  little  understanding  of  the  theoretical  basis 
for  proper  system  design  using  the  language.  We 
believe  this  approach  is  not  appropriate  for  teach¬ 
ing  the  language  as  a  design  tool. 
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College  court** ,  on  the  other  hand,  emphasize 
Individual  study  and  research  In  conjunction  with 
lecture  presentation*.  The  result  Is  that  college 
students  are  taught  to  apply  the  language  as  a  tool 
f or  problem  solving  and  to  draw  Inferences  from 
this  activity  an  to  what  new  applications  aay  be 
developed.  V*  believe  that  college  faculty  should 
be  taught  In  the  saae  way.  We  also  believe  that  It 
Is  not  reasonable  for  the  average  faculty  aeaber  to 
atteapt  to  learn  Ada  by  self-study,  a*  Is  possible 
with  other  languages.  Ada  Is  too  coaplex  and 
requires  coo  auch  cultural  asslallatlon  for  this  to 
be  effective. 

We  believe  It  Is  laporcanc  In  teaching  Ada  to 
college  faculty  to  take  advantage  of  the  varied 
background*  of  the  participant*.  This  can  be  done 
by  relaying  questions  to  aeaber*  who  aay  be  able  to 
answer  thea,  by  having  aeaber*  give  presentations, 
by  having  thea  help  one  another  with  prograaalng 
exercises,  and  ocher  slallar  techniques. 

We  believe  that  one  of  the  aost  laportanc 
Ideas  to  get  across  In  teaching  Ad*  Is  the  concept 
of  software  maintenance  and  how  Ada  slapllfle*  It. 
We  Intend  to  highlight  this  feature  by  requiring 
the  participant*  to  modify  existing  code  under 
several  different  conditions. 


CLASSROOM  INSTRUCTIONAL  ACTIVITIES 
Classrooa  Material* 

The  primary  classrooa  materials  consisted  of  a 
series  of  overhead  transparencies  containing  key 
points  of  Information  and  aany  exaaples.  These 
class  notes  have  been  developed  over  several  years 
and  tested  in  numerous  courses.  Students  were 
given  paper  copies  to  facilitate  note-taking  and 
permit  use  as  a  reference.  These  were  reduced  In 
size,  four  overheads  per  page  of  class  notes,  to 
alnlalze  duplication  costs. 

Texts 

Two  texts  were  used  as  primary  references  for 
the  sealnar: 

An  Introduction  to  Ada.  2nd  Edition 
S.  J.  Young,  J.  Wiley,  1984 

Software  Engineering  with  Ada.  2nd  Edition 
G.  Booch,  B.  Cuaalngs,  1985 

Young,  prlaarlly  a  language  text,  provided  an 
excellent  supplement  to  the  topics  covered  in 
class.  However  thorough  the  classroom  explana¬ 
tions,  few  students  are  capable  of  assimilating  all 
Che  details  in  one  exposure.  This  material  is 
absorbed  more  completely  through  a  combination  of 
classroom  discussion,  outside  readings,  and  labor¬ 
atory  exercises.  Young  was  considered  very  under¬ 
standable  by  most  of  the  participants;  for  those 
with  weaker  backgrounds,  more  elementary  texts  were 
recommended  for  the  first  reading.  Booch,  with  its 
emphasis  on  software  engineering  principles  and 
software  design,  was  a  valuable  addition  to  the 


regular  readings.  A*  early  In  the  course  as  pos¬ 
sible,  students  must  have  enough  language  features 
to  solve  meaningful  laboratory  exercises,  but  they 
must  also  understand  the  principles  of  software 
design  with  Ada  In  order  to  use  Ada's  features 
properly.  These  dual  need*  result  In  a  competition 
for  prime  classrooa  tlac  early,  not  only  In  this 
course,  but  In  any  course.  Since  students  aust 
have  the  language  In  order  to  write  code,  the 
language  usually  come*  first.  While  the  basics  of 
software  engineering  and  object-oriented  design 
were  Included  In  later  class  periods,  outside 
reading*  In  Booch  Introduced  these  principle* 
earlier  than  classrooa  claw  could  perelt. 

Use  of  the  Ada  Language  Reference  Manual 

The  Ada  LRM  (ANS1-M1L-STD-1M5A),  the  only 
coapletely  reliable  source  of  Ada  Information,  Is 
an  essential  student  reference.  Each  participant 
was  given  a  copy  of  the  LRM  at  the  first  class 
aeetlng.  It  Is  of  vital  laportance  chat  the  stu¬ 
dent  become  familiar  with  the  LRM  a*  soon  c*  pos¬ 
sible.  However,  to  anyone  not  accustomed  to  using 
reference  swnuals,  the  Ada  LRM  can  be  both  Intimi¬ 
dating  and  confusing.  Overheads  sutde  directly  froa 
the  printed  LRM  page  were  used  frequently  In  the 
class  presentations  to  Illustrate  the  use  of  par¬ 
ticular  feature*  by  mean*  of  the  aany  excellent 
exaaples  contained  In  the  LRM.  This  use,  In  the 
context  of  the  class,  can  go  a  long  way  coward 
reducing  LRM-anxiety.  Later  on,  when  the  students 
have  a  firmer  foundation  In  the  language,  the  LRM 
Is  regularly  used  to  answer  questions  raised  In 
class.  (The  class  notes  also  sake  frequent  refer¬ 
ence  to  specific  coplea  In  the  LRM.)  Two  priswry 
reasons  that  the  LRM  Is  confusing  are  (1)  preci¬ 
sion  In  any  language  tends  to  Increase  the  coaplex- 
lty  and  (2)  aany  forward  and  backward  references 
will  Inevitably  couch  on  soae  features  of  which  the 
student  has  little  or  no  knowledge.  The  first 
difficulty  is  dealt  with  by  Increasing  familiarity 
with  the  style  and  dissecting  sentences,  with  the 
class,  to  analyze  precisely  what  is  being  stated. 
The  effect  of  the  second  gradually  diminishes  a* 
the  student  learns  aore  of  the  language  to  chat 
fewer  references  are  obscure. 

Classrooa  Library 

In  addition  to  the  texts  and  materials  sup¬ 
plied  to  every  student,  a  fairly  extensive  collec¬ 
tion  of  reference  materials  was  made  available. 
These  included  numerous  langusge  texts,  Ada  refer¬ 
ence  books,  periodical  literature  relating  to 
current  activities  in  Ada,  and  reference  materials 
for  VAX/VMS,  VAX/ Ada,  and  the  EOT  editor.  Also  in 
the  library,  as  examples  of  available  course  mater¬ 
ials,  were  (a)  course  materials  used  in  the  Ada 
training  program  at  Keesler  Air  Force  Base,  (b) 
the  courses  L202  (Basic  Ada  Prograaalng),  L305 
(Advanced  Ada  Topics),  and  L401  (Real  Time  Systems 
in  Ada)  developed  as  part  of  the  US  Army  Model  Ada 
Training  Curriculum  by  SofTech,  (c)  materials  for 
the  tutorials  Beginning  Ada  and  Advanced  Ada  offer¬ 
ed  by  ASEET  (Ada  and  Software  Engineering  Education 
Team)  and  (d)  overheads  available  for  use  with 
Booch' s  Software  Engineering  (1st  Ed.). 
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Several  of  the  reference  book*  were  thought  to 
W  Important  enough  to  that  several  copies  were 
acquired  for  the  library: 

national*  for  the  D««l>n  of  eh*  Ad*  frogram- 
mtn*  language;  in  addition  to  being  a  good 
•oure*  of  examples,  thl*  la  an  Invaluable 
source  of  answer*  to  *uch  mutation*  a*,  "Why 
w«r«  Ad*  loop*  designed  to  b*  to  simple  wh*n 
ta*k*  ar«  *o  complicated!" 

ala  a*  a  Second  language,  Korean  Cohen, 
HcCrav-Hlll,  1916:  Thl*  book,  *o**wher* 
between  an  a4vane*4  text  an4  a  readable  ver- 
•lon  of  th«  r«f«r«nc«  manual,  provided  valu¬ 
able  Information  to  th«  acre  a4vanee4 
participant*. 


Class/laboratory  Dally  Format 

The  *ch*4ul*  for  data  and  lab  period*  va* 
established  early,  and  work,  '  to  effectively,  for 
both  ttudent*  and  instructor/ .  that  It  va*  aodlfltd 
only  for  tpeclal  clrcu**ca’-'f'  such  <)  guett  lec- 
tur*«,  Thl*  tchedul*  va*: 

8:30  -  9:20  #.».  CUa* 

9:30  -  11:00  t*b6r»>ory 
11:10-12:00  Slate 

12:00  -  1:00  p.a.  lunch 

1:00  -  2:30  laboratory 
2:40  -  3:30  Clatt 
3:30  -  3:00  laboratory 


Software  Component*  with  Ada,  Crady  looch, 
Benjamin  Cuaalngt,  1987:  An  affordable  exam¬ 
ple  cf  the  *oftvar«  component*  lnduttry  pre¬ 
dicted  to  develop  a*  a  r«*ulc  of  Ada  package*. 

Order  of  Pr*««ntatlon  of  Topic* 

The  moat  natural  way  to  presenc  a  language  a* 
large  and  complex  a*  Ada  1*  top-down,  with  an 
overview  of  the  hlatory,  phllotophy,  and  *tructur* 
of  the  language  providing  a  context  for  the  de¬ 
tail*.  Uhtn  the  court*  Involve*  laboratory  exer- 
cltet  (unquestionably  the  beet  way  to  teach  a 
language)  and  1*  pretented  a*  an  Incentive  expo¬ 
sure  with  the  end  loom!')  only  a  few  week*  after 
the  beginning,  compromU.  .  mutt  be  made  between  the 
moat  logical  order  of  preientatlon  and  the  need  to 
have  detail*  nec**«ary  for  writing  program*  In  the 
laboratory. 

On*  compromise  resulted  In  postponement  of  the 
history  until  late  In  the  course:  thl*  was  prob¬ 
ably  a  mistake.  The  greater  appreciation  for  the 
language  through  knowing  It*  historical  context, 
would  be  worth  the  small  delay  in  writing  more 
complex  program*. 

Another  compromise,  which  was  pcdagoglcally 
sound  and  worked  well,  was  to  cover  the  language 
feature*  In  a  natural  order,  but  to  treat  them 
lightly  the  first  time  through  and  then  go  back 
again  (and  aometlme*  again)  with  more  detail  each 
time.  The  basic  order  of  topics  (with  minor 
variation*  to  accommodate  specific  needs  for  lab 
exercises)  was: 

Overview  of  the  language 
Program  structure 

Discrete  types  (vltn  necessary  I/O) 

Statement*  (simple  and  compound) 

Procedures  and  functions 

Package* 

Input/Output  (incl.  flies  and  formatting) 

Scope  6  Visibility  (lncl.  Block  statement) 
Separate  compilation 

Object-oriented  design  &  Software  engineering 

Exceptions 

Generic  units 

Access  types 

Tasking 


The  laboratory  was  also  available  during 
evening  hours,  on  weekends,  and,  by  popular  demand, 
early  In  the  morning.  The  50-mlnut*  class  periods, 
Interspersed  with  1-1/2  hour  lab  periods  seemed  to 
optimise  the  learning  experience. 

Participant* 

Attending  the  Seminar  were  fourteen  partici¬ 
pant*  fro*  fourteen  institutions  which  ranged  from 
2-y**r  colleges  through  universities  and  included  a 
U.S.  Army  graduate  school.  Five  of  the  partici¬ 
pant*  possessed  a  doctoral  degree,  and  all  had 
advanced  degrees  In  computer  science.  In  an  at¬ 
tempt  to  attain  a  relatively  homogeneous  group,  the 
prerequisite  of  "experience  In  on*  or  more  modern 
programming  language*,  preferably  Including  Pascal" 
was  specified. 

Every  Ada  course  In  which  any  of  the  seminar 
staff  have  been  Involved  has  had  a  heterogeneous 
mix  of  participant  backgrounds;  even  with  the 
stated  prerequisite,  this  course  va*  no  exception. 

The  level  of  experience  Included  those  who  had 
taught  advanced  Ada  courses,  those  who  had  taught 
Computer  Science  courses  but  had  only  a  cursory 
introduction  to  Ads,  and  those  with  substantial 
computer  background  to  whom  Ada  was  completely 
new. 

A  particularly  gratifying  response  on  all  the 
end-of-eourse  evaluations  Indicated  that,  In  spite 
of  the  vsrlance  In  preparedness  among  participants, 
"The  seminar  was  very  worthwhile  for  me."  Appar¬ 
ently  the  complexity  of  Ada  lends  Itself  well  to 
learning  it  on  many  levels.  The  beginners  learned 
Ada  concepts  and  structure  without  (In  some  cases? 
appreciating  all  the  details,  while  the  most  exper¬ 
ienced  found  that  their  prior  knowledge  of  Ada  was 
dravn  together  and  the  finer  details  were  filled 
In.  The  variation  was  used  to  advantage  In  the  lab 
assignments  with  stronger  participants  on  teams 
with  weaker  ones;  the  weaker  ones  and  the  stronger 
ones  learned  from  each  other— on  the  one  hand 
learning  about  programming  In  Ada,  and  on  the  other 
hand  appreciating  points  of  difficulty  their  stu¬ 
dents  might  have. 
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One  surprising  observation  w.-j*  that,  in  spice 
of  the  high  level  of  experience  of  che  class,  the 
course  syllabus  was  covered  more  tlowly  than  In  a 
typical  undergraduate  class.  This  was  due  In  part 
because  of  the  many  excellent  penetrating  ques¬ 
tions.  As  a  result,  the  Material  was  alto  studied 
In  grdater  depth. 

Coast  Lecturer  Program 

because  of  elm*  constraints,  only  two  guest 
lecturers  were  brought  In.  James  E.  Schell,  form¬ 
erly  Director  of  the  US  Army's  Center  for  Software 
Lifecycle  Support,  discussed  the  background  and 
political  Issues  surrounding  Ada's  development  and 
use.  Captain  David  A.  Cook,  US  Air  Force  Academy, 
spoke  on  tasking.  Both  were  considered  by  the 
participants  to  be  valuable  additions  to  the 
course. 


LABORATORY  ACTIVITIES 


Overview 


Ten  programming  cxerctsea  were  given  over  the 
four  week  period.  The  programs  were  of  ever  In¬ 
creasing  complexity  and  length  and  were  coordinated 
with  the  material  covered  In  lectures.  Each  new 
programming  exercise  required  the  programmer  to  use 
new  features  of  the  language.  The  assignments  were 
scheduled  to  be  assigned  after  the  language  feature 
had  been  covered  In  the  lectures.  All  of  the 
assignments  were  made  In  written  form  and  placed 
electronically  Into  each  participant's  directory 
separately  and  at  appropriate  times. 

Even  though  all  of  the  students  were  seasoned 
computer* scientists  most  preferred  the  assignments 
in  hardcopy  form.  This  was  evidenced  by  the  fact 
that  most  students  when  given  an  assignment  elec¬ 
tronically  Immediately  proceeded  to  get  a  hardcopy 
to  read  as  opposed  to  reading  It  at  the  screen. 

There  were  three  team  projects.  On  the  first 
two  team  projects  the  team  site  was  held  to  2  or  3 
per  team.  The  final  week-long  project  Involved  the 
use  of  separate  procedures,  generic  and  nongenerle 
packages,  exception  handling,  and  tasking.  The 
team  sire  was  Increased  to  3  or  A  members  for  the 
final  project. 


The  following  is  a  Hat  of  the  programming 
exerclaea  showing  the  Ada  feature  that  was  stressed 
for  each  particular  lab: 


Exercise 

1 

2 

3 

A 


Title 

First  Ada  Program 
Sum  of  Integers 

Square  Root 
Payroll 


Ada  Feature 

VAX/EDT/ACS 

Program  Structure, 
Text  10,  Int_I0 

If,  Loop,  Function 

File  Type,  Procedure 


Exercise 

5 

6 

7 

8 

9 

10 


Title 

Hath  Library 
Income  Tax 


Ada  Feature 

SonCenerlc  Package, 
Exceptions 

Array,  Record, 
Nontext  Flies 


Bingo,  Team  rroject  Abstract  Data  Type, 
Package,  1/0, 
Enumeration  Types 

Stack  Package  Cenerlc  Package 

Bridge,  Team  Project  Abstract  Data  Type, 
Package,  I/O, 
Enumeration  Types 


TuAda  Compiler 
Team  Troject 


Tasking,  Separate 
Compilation, 
Cenerlc  Packages 


Team  Prelects 

The  first  team  project  proved  to  be  an  Inter¬ 
esting  problem  In  that  once  the  package  was  com¬ 
pleted,  the  specification  only  was  given  to  another 
team  which  was  required  to  write  a  driver  program 
to  test  the  package.  What  was  considered  Intuit¬ 
ively  r&vious  to  the  package  specification  writer 
was  not  always  crystal  clear  to  the  user  of  that 
package.  The  proper  choice  of  function  and  pro¬ 
cedure  names  and  the  parameters  required  by  these 
subprograms  proved  to  be  a  real  challenge  to  the 
participants.  This  was  che  first  attempt  by  che 
participants  at  object-oriented  design  and  caused 
them  to  look  at  the  problem  In  a  different  light. 
It  was  also  their  first  use  of  enumeration  types 
and  enumeration  I/O. 

The  second  team  project  was  similar  to  che 
first  In  that  object-oriented  design  was  required 
as  well  as  enumeration  1/0.  The  team  members  were 
different  from  che  first  project  and  an  attempt  was 
made  to  match  more  advanced  participants  with  chose 
lets  advanced.  Things  went  more  smoothly. 

The  major  large  project  used  larger  teams 
beesuse  It  vtt  multlphaslc  In  nature  and  required  a 
larger  programming  effort.  The  project  waa  a 
miniature  compiler  project  with  three  parts:  a 
scanner,  a  parser,  and  a  code  generator.  This 
compiler  was  different  from  most  In  that  a  buffer 
holding  tokens  was  placed  between  the  scanner  and 
che  parser  and  another  buffer  holding  action  rou¬ 
tines  and  tokens  was  to  be  placed  between  che 
parser  and  che  code  generator. 

The  scanner  waa  a  cable  driven  finite-state 
automaton;  the  students  were  given  the  cable  and 
the  algorithm.  It  was  simple  enough  but  an  under¬ 
standing  of  Its  relationship  to  the  symbol  cable 
proved  to  be  a  major  problem.  It  was  assumed  chat 
most  computer  scientists  had  rudimentary  knowledge 
of  compilers;  this  assumption  proved  to  be  false. 
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The  parser  «a*  the  central  controlling  unit 
And  wt*  an  ltd)  table  driven  parser.  The  team* 
were  given  the  parting  table;  the  production  rule* 
and  the  parting  algorithm  were  provided.  The 
etudente'  innate  curiosity  wat  greatly  underesti¬ 
mated.  Inttcad  of  treating  the  problem  at  Jutt  an 
exercise  uting  tasking,  they  wanted  to  know  more 
about  compiler*  and  not  only  how  the  parting  table 
wat  uted  but  how  it  wat  generated. 

The  code  generator  wat  the  catlett  becaute 
syntax-directed  trantlatlon  wat  uted  and  the  name* 
of  the  action  routlnet  were  eabedded  directly  into 
the  production  rulet.  The  code  generator  had  but  a 
few  action  routlnet  that  generated  qusdrules. 


C0MNJTER  SYSTEM  SUfrORT 
System  Configuration 

Hardware:  Computer  tupporc  for  the  aealnar 
wat  provided  by  a  VAX-1 1/780  which  contained  16 
Mbytet  of  memory,  968  Hbytet  of  dltk  storage,  and 
*0  portt.  A  Digital  LA-210  aerial  printer  wat 
tpooled  reaotely  for  hardcopy  output.  The  16  VT- 
220  classroom  terminal*  were  connected  to  the 
computer  acrott  the  campus  by  ttatittlcal  multi¬ 
plexers  and  a  Ml  COM  600  Port  Selector.  Thlt  con¬ 
figuration  proved  adequate  for  thlt  tlxe  prograa, 
even  though  the  tyttea  wat  thared  at  tlaet  with  up 
to  20  Fortran  prograaalng  atudenca  and  variout 
retearchert.  A  tyttea  of  thlt  tlxe  ahould  be  able 
to  accoaaodate  20  to  30  Ada  students  if  properly 
aanaged. 

Software:  The  Digital  Equipment  Corporation 
VAX  Ada  coapller  and  the  VHS  operating  tyttea 
envlronaent  provided  excellent  tupporc  for  the 
Sealnar.  The  tyttea  wat  aanaged  at  recoaaended  in 
che  coapller  lntcallatlon  Interaction*.  Inter¬ 
active  utert  were  given  a  Working  Sec  (phytlcal 
aeaory)  allocation  of  1500  paget  (.75  Hbytet).  A 
batch  queue  wat  eatabllthed  with  3500  paget  (1.75 
Hbytet)  working  tec  for  coapilatlont.  Adi  com¬ 
pilations,  even  wl'h  che  DEC  production  quality 
coapller,  require  a  great  deal  of  aeaory,  and  will 
generate  huge  nuabert  of  page  fault!  (dltk  readt) 
if  they  are  not  given  enough.  Running  coapilatlont 
froa  a  batch  queue  lapotei  a  Halt  on  che  nuaber  of 
coapllet  running  alaultaneoutly,  allow*  the  Job*  to 
ute  all  che  aeaory  they  need,  and  flnlah  quickly. 
It  alto  allow*  participant*  to  be  working  on  other 
catk*  while  che  coapilatlont  are  running.  The 
retulc  la  efficient  ute  of  the  tyttea  and  alnlaal 
degradation. 

Syttea  Organization 

Faculty  and  participant  account*  were  placed 
In  che  saae  Uter  Identification  Code  (UIC)  Croup  to 
facilitate  coaaunlcaclons  and  file  trantfera.  All 
assignments  were  aade  by  broadcaat  transmission  of 
filet  froa  faculty  to  user  directories.  Faculty 
had  Croup  privilege,  allowing  thea  access  to  par¬ 
ticipant  flies  for  review  and  critique.  Partici¬ 
pants  wishing  to  do  so  could  set  their  default  file 
protection  to  preclude  other  participants  froa 


gaining  access  to  their  file*.  The  grouping  of 
directories  was  intended  to  be  a  technique  to 
alnlalse  printing  requirements,  but  we  found  that 
even  computer  rtienclscs  are  addicted  to  paper ,  and 
wanted  tu  print  out  virtually  everything  they  did, 
even  though  it  was  not  really  necessary. 


SEMINAR  10C I ST  ICS 
eiassroomflaboratory  facilities 

lectures  were  presented  in  a  classroom  sep¬ 
arate  froa  the  laboratory  but  nearby.  The  labora¬ 
tory  was  one  of  the  noraal  University  student 
terainal  labs,  configured  for  up  to  19  terminals. 
This  arrangement  proved  satisfactory  in  all  res¬ 
pects.  There  were  no  distracting  terminal  or 
systea  activities  during  lectures,  and  the  movement 
between  rooas  provided  a  good  break.  Additionally, 
the  use  of  two  room*  allowed  the  sealnar  faculty  to 
work  to  prepare  lectures,  lab  exercises,  etc.  in 
whichever  rooa  was  not  in  use.  The  only  problem 
which  arose  was  that  tome  of  the  participants 
wanted  to  work  long  or  unusual  hours,  and  che 
control  of  the  room  key  became  a  logistics  exercise 
in  Itself. 

8udget 

The  budget  total  of  554,000  covered  faculty 
salaries  and  expenses,  course  materials,  computer 
operation  and  aalncenance,  seminar  logistics,  and 
overhead.  Participant*  were  not  paid  a  stipend, 
but  their  on-caaput  lodging  wat  paid.  Funding 
support  wat  provided  through  a  U.S.  Army  grant. 


Seminar  Staff 

Three  people  performed  variout  aajor  tasks  in 
tupporc  of  the  sealnar.  The  Academic  Director  wat 
che  priaary  instructor;  thus,  the  primary  selection 
criterion  was  lengthy  teaching  experience,  includ¬ 
ing  the  teaching  of  Ada.  The  Lab  Director  develop¬ 
ed  and  administered  che  prograaalng  exercises; 
thus,  che  priaary  qualifications  were  facility  with 
the  language  and  the  ability  to  work  well  with 
people.  The  Syttea*  and  logistics  Director's  job 
was  to  handle  all  tyttea  action*  and  logistics 
arrangements.  The  qualifications  for  thlt  job  were 
primarily  managerial.  Due  to  the  critical  Impor¬ 
tance  of  good  computer  support,  It  it  essential 
that  thlt  person  occupy  a  position  of  authority 
with  respect  to  the  coaputer  tyttea  and  the  people 
who  directly  operate  it.  Other  pertonnel  Involved 
were  the  regular  coaputer  tervlcet  technical  tup¬ 
porc  and  administrative  staff  of  the  host 
Institution. 
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ANALYSIS  Of  rARTlCtfAXT  RES  FOSSES 

rartlclpant  reaction*  to  the  program  were 
obtalnid  through  informal  discussion*  during  the 
seminar,  during  a  scheduled  verbal  discussion 
session,  and  through  comprehensive  written  assess¬ 
ment*.  Comment*  can  ho  categorized  aa  follow*: 

1.  rrogran  length:  The  four  week*  van  found  to 
he  adequate  hut  ambitious  for  the  material 
covered.  Hoat  participant*  would  have  prefer¬ 
red  more  time,  hut  agreed  that  a  longer  pro- 
gran  la  a  problem  for  most  college  faculty 
without  other  euaner  Income. 

2.  frogran  objective*:  There  waa  considerable 
niaunderatanding  of  the  progran  objective*. 
Sone  participant*  were  correctly  expecting  an 
entry  level  hut  co*prchcn*lve  courae  compar¬ 
able  to  the  fir*t  one-«cneater  graduate  Ada 
courae.  Other*  expected  an  advanced  progran 
which  began  fron  a  good  foundation  in  the 
language.  Tht*  perceived  anblgulty  in  the 
Stated  objective*  wa«  *aid  to  he  the  cauae  of 
the  diversity  of  experience  level*,  and  re¬ 
sulted  in  both  beginning  and  advanced  partic¬ 
ipant*  gaining  lei*  than  they  had  hoped  fro* 
the  progran. 

3.  Management  of  diverge  background*:  Several 
*ugge*tlon»  were  made  for  taking  better  advan¬ 
tage  of  the  advanced  background*  of  *o*e 
participant*.  Such  tactic*  a*  optional  ad¬ 
vanced  lecture*,  more  itructured  tutoring  of 
the  beginner*  by  the  advanced,  having  advanced 
people  actually  pre*ent  topic*  fro*  their 
experience  were  propoxed.  The  belt  tactic, 
however,  was  believed  co  be  separate,  better 
defined  program  for  beginner*  and  advanced. 
The  conaemu*  waa  that  even  greater  benefit* 
could  be  gained  if  the  participant*  were  of 
nore  comparable  background*  Ada-wi*e. 


CONCLUSIONS  ASO  RECOMMENDATIONS 
frogran  length  and  conpoiition 

Four  week*  *eem  co  be  the  beat  conpronUe 
between  the  divergent  liiue*  of  cine  required  to 
preienc  an  exhaustive  treatment  of  the  subject  with 
adequate  lab  experience  and  cine  available  to 
prospective  attendees  with  ocher  coaalcnencs  and 
opportunities. 

Contract  timing 

The  availability  of  funds  nine  nonths  before 
the  seminar  enabled  recrultnent  of  participants 
beginning  In  January,  allowing  wide  dlssealnatlon 
of  progran  Inforaatlon.  Most  participants  applied 
In  March,  enabling  conflroatlons  to  be  Issued  In 
late  April.  Issuance  of  conflrnatlons  In  March 
would  be  preferable,  but  It  Is  difficult  to  get 
applications  subaltted  In  tine  to  do  that. 


Academic  consideration* 

The  seminar  was  so  successful  that  there  are 
very  few  recoamendacton*  for  change.  One  would  be, 
as  described  above,  to  keep  the  history  of  Ada  in 
the  beginning  of  the  «e*inar.  While  this  night 
mean  doing  simple  programming  exercise*  for  a 
little  longer,  until  the  Ada  feature*  necessary  to 
more  challenging  program*  are  studied  in  class, 
this  trade-off  would  be  advisable.  Another  pos¬ 
sible  change  would  be  to  have  a  more  homogeneous 
group  of  participants,  if  that  1*  possible.  Since 
the  less  well-prepared  participant*  found  the 
course  to  be  valuable,  It  would  be  unfortunate  to 
exclude  them.  While  they  would  have  received 
greater  benefit  had  they  been  more  familiar  with 
Ada  concepts,  if  not  with  the  detail,  their  pre¬ 
sence  did  not  diminish  the  value  to  other  partici¬ 
pant*  and  may  well  have  increased  it  in  some  res¬ 
pect*. 

Laboratory  consideration* 

The  participant*  didn't  get  enough  practice 
with  tasking.  Not  all  of  the  team*  got  their  toy 
compiler  to  the  stage  where  they  could  implement 
the  buffer  controlling  tasks.  One  tea*  that  did 
get  that  far  had  sone  problem  and  decided  to  use 
the  symbolic  debugger.  Everytine  they  used  the 
debugger,  the  program  worked  fine,  but  it  would  not 
run  without  it.  This  presented  a  very  interesting 
problem  In  that  the  asynchronous  casks  did  not  work 
properly  unless  the  debugger  was  Inserted  into  the 
equation  and  it  then  changed  the  tine  so  that  the 
task  worked  properly.  This  experience  really  drove 
home  the  point  that  solving  tasking  problems  Is  not 
as  easy  a*  debugging  sequential  code.  Any  added 
disturbance,  the  symbolic  debugger  In  this  case, 
can  cause  the  timing  of  the  asynchronous  processes 
co  be  altered  dramatically. 

In  retrospect,  a  project  that  required  less  of 
a  learning  curve  and  one  that  create*  less  curio¬ 
sity  could  possibly  have  provided  a  more  meaningful 
tasking  experience.  A  tasking  problem  Involving 
something  chat  all  of  the  participants  were  already 
familiar  with  night  have  enhanced  the  tasking  part 
of  the  project.  The  Ada  experience  was  valuable. 
The  teamwork  experience  was  valuable  (teachers  are 
accustomed  co  working  alone).  Dealing  with  soft¬ 
ware  engineering  aspects  of  a  larger  team  project 
was  also  a  vary  valuable  experience. 

Croup  site  and  composition 

The  group  size  of  fourteen  was  good  for  pro¬ 
gram  administration,  but  up  to  23  could  have  been 
accommodated  with  the  facilities  and  system  support 
available.  The  group  composition  of  all  computer 
scientists  was  good  in  that  Instruction  in  elemen¬ 
tary  computer  techniques  was  not  required,  but 
there  was  still  a  great  diversity  In  backgrounds  In 
the  group.  It  Is  clear  that  more  consistent  expec¬ 
tations  of  the  program  arc  needed;  It  Is  much  less 
clear  how  that  can  be  achieved. 
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HOCHAPHlCAt.  DATA 


ludget  considerations 

The  budget  was  adequate  (or  sh*  coot  ti«N 
which  were  Included.  It  would  he  no-  idvanvageous 
to  the  program  1(  sufficient  (undo  could  he  made 
available  to  provide  participant  stipends  •«  well. 
Hoot  college  faculty  supplement  their  academic  year 
Income  by  obtaining  teaching  contracts  or  research 
(ellowehtpx  In  the  summer.  It  lx  difficult  for 
many  to  give  up  thexe  summer  activities  In  order  to 
attend  a  semtnar  for  which  they  are  not  paid. 

Staff  requirements 

The  staff  of  three  profesxlonalx  plus  support 
froa  the  noraal  coaputcr  services  staff  was  ade¬ 
quate.  Fewer  than  three  would  not  allow  the  diver¬ 
sity  of  skills  required  for  heat  success,  and  would 
lapact  staff  ability  to  react  to  unexpected  situa¬ 
tions  such  as  unusually  diverse  participant  back¬ 
ground.  Dedicated  clerical  and  system  support  lx 
not  required  If  the  host  staff  are  responsive  to 
requests  and  problems.  Most  critical  of  the  host 
support  requirements  Is  data  communications  If  the 
lab  Is  remote  from  the  computer  center. 

Seminar  results  vs,  planning  model 

Observed  results  and  participant  responses 
supported  the  validity  of  the  premises  sec  forth  In 
the  planning  model.  The  approach  of  this  seminar, 
with  Intensive  Instruction  coupled  with  extensive 
laboratory  experience  was  successful  with  this 
group.  It  was  the  consensus  of  participants  and 
faculty  that  a  shorter,  less  detailed  seminar  would 
not  have  provided  the  Information  required  In  order 
for  the  participants  to  become  "Ada  evangelists" 
at  their  home  Institutions. 

Conclusion 


Dr.  M.  Susan  klchman  Is  Director  of  the  Ada  Educa¬ 
tion  and  Software  Development  Center,  and  Associate 
Frofcxsor  of  Mathematics  and  Computer  Science  at 
The  Pennsylvania  State  University  at  Harrisburg, 
Middletown,  Pennsylvania.  Dr.  Klchman  Is  a  grad¬ 
uate  of  the  University  of  California,  Herkeley,  and 
received  the  Ph.D.  In  Mathematics  from  the  Univer¬ 
sity  of  Aberdeen,  Scotland. 

Dr.  Charles  G.  Petersen  is  Associate  Professor  of 
Computer  Science  at  Mississippi  State  University. 
Dr.  Paterson  lx  a  graduate  of  Iowa  State  Univer¬ 
sity  and  holds  the  M.S.  degree  In  Computer  Science 
and  the  Ph.D.  degree  In  Higher  Education  from  Iowa 
State  University. 

Mr.  Donald  C.  Fuhr  Is  Director  of  Computer  Services 
at  Tuakegee  University,  Alabama.  Me  Is  a  graduate 
of  Oregon  State  University  and  received  the  M.S. 
degree  In  Engineering  Management  from  the  Univer¬ 
sity  of  Alaska. 


This  seminar  was  highly  successful  In  vir¬ 
tually  all  respects.  While  the  classroom  and 
laboratory  planning  and  execution  were  primary 
factors  In  this  success,  attention  to  participant 
convenience  and  comfort  were  also  Important  to  the 
overall  learning  environment  In  a  residence  situa¬ 
tion.  Credit  must  also  be  given  to  the  partici¬ 
pants  themselves,  who  quickly  became  a  very  close- 
knit  group  and  socialised  together  away  from  the 
seminar.  The  four  weeks  became  a  very  personal  and 
meaningful  experience  for  all  Involved. 
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COBOL  1“  Mt 

by 

Jagdlah  C.  Agrawal 
Computer  Solenee  Department 
Embry  Kl<ldl«  Aeronautical  University 


n.tn.t;  Hul t i-m 11 1  ion  lino*  of  COBOL 
code  baa  been  in  uaa  in  large 
organisations  for  a  long  tint.  Vith 
changing  requirements,  auoh  of  thia  coda 
1*  randy  for  a  major  system  ehango 
requirement,  or  for  a  redesign.  it  the 
aaaa  time,  many  iarga  organiaationa  with 
auoh  ooda  have  ohangad  tbalr  language 
atandard  from  COBOL  to  Ada.  However, 
tbaaa  organiaationa  and  thair  aupport 
contractors  bava  vary  valuabla  human 
raaouroaa  of  aaaaonad  COBOL  programmers 
who  oan  bt  anally  ratralnod. 


Tbara  seems  to  ba  some  controvaray  in 
Academia  about  how  aaay  or  difficult  it 
aay  ba  to  train  a  COBOL  prograaa or  in  Ada. 
In  thia  papar,  tha  author  ia  propoalng  a 
f raaawork  for  an  introductory  oouraa 
apaolally  daalgnad  for  tha  olaaa  of 
axparlanead  COBOL  programmers,  In  thia 
approaoht  wo  ara  capitalising  on  the 
pravloua  knowledge  of  tha  atudant  for  tha 
purpose  of  lntroduolng  new  knowledge. 


IMIlQPUCnSl 


Tha  tara  'packaging*  la  familiar  to 
ayataa  developers  who  have  bean  using  tha 
lourdon  and  Conatantlne'a  Structured 
Design  techniques  [1],  which  uses  thia 
tera  to  refer  to  the  assignaent  of  aodules 
of  a  total  systea  into  seotions  handled  as 
dlstinot  physloal  units  for  execution  on  a 
aaohine.  COBOL  programmers  who  have  been 
praoticing  Structured  Design  teohniques 
are  very  likely  to  find  Ada's  packaging 
capabilities,  separation  of  package 


specification  and  package  body*  and 
separata  ooapllatton  vary  attractive  and 
enjoyable.  Tha  prospects  of  gaining 
control  on  'visibility'  and  'scope'  and 
thereby  on  abstraction.  hiding, 
localisation  and  modularity  will  aake 
their  learning  of  Ada  axeltlng  and 
ooaaensurate  with  the  software  engineering 
praotloaa  they  are  familiar  with  already! 

While  in  the  literature  there  have 
been  papers  and  books  written  on 
ooaparlaon  between  Paaeal  and  Ada,  there 
has  been  little  work  in  tha  area  of 
exaalnlng  Ada,  capitalising  on  the 
knowledge  of  COBOL  prograaaers.  I  believe 
that  the  job  of  training  COBOL  prograaaers 
will  be  aade  auoh  easier  if  extensive 
literature  existed  on  comparison  and 
oontrast  between  COBOL  and  Ada,  This 
paper  makes  a  small  contribution  towards 
such  literature  and  it  provides 
Interesting  siailarlties  and 
dissimilarities  of  praotiolng  software 
engineering  with  Ada.  For  example,  the 
data  structures,  control  structures,  and 
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th«  moduli  structures  in  chi  two  languages 
will  hi  compared  and  contrasted  with 
examples. 

In  large  organisations  lika  th«  U.S. 
Army  Information  Systems  Engineering 
Command  (1SEC),  whirs  COXOL  has  biin  tha 
programming  languaga  of  eholca  for  quits 
aomi  time,  now  chart  is  t  ntnd  to  train  a 
vary  iarga  numbar  of  aaaaonad  COBOL 
programmara  in  Ada.  Howavar,  at  tha 
outatt,  Ada  appaara  to  ba  intimidatingly 
largo  and  acmplax  oomparad  to  COBOL.  Sueh 
paroaptiona  oontributa  towards  making  tha 
Job  of  training  axparlanead  COBOL 
programmara  in  Ada  a  vary  difficult  and 
challenging  task.  Howavar,  sarious 
raaaaroh  to  identify  aoma  strong 
similarities  in  tha  two  languages  and  in 
tha  ways  of  practicing  software 
engineering  with  tha  two  languages  oan 
make  tha  initial  many  lessons  of  a 
training  program  vary  easy  for  tha  COBOL 
programmers  to  understand.  Tha  author 
believes  in  tha  principle  that  Initial 
aim m  hratiia  wore  amggaai.  This  in  turn 
increases  the  productivity  from  tha 
training  program. 


£££&  £QI  XJUXJUIfi  £XJt££X£££X&  AMU. 
urn t£XIX£  £fll£l.  IIflgJUMM£U 

Acquirements  for  redesigning  large 
systems  or  developing  new  ones  in 
environments  that  are  adjusting  to  change 
in  the  implementation  languaga  standard 
from  COBOL  to  Ada  are  expansive  to 
implement  and  they  involve  a  vary  large 
lnvestuant  in  "porting*  the  human 
resources  from  one  environment  to  another. 
Seasoned  programmers  of  the  old 
environment  with  considerable  exparlanoe 
with  the  outgoing  environment  find 
themselves  under  pressure  and  stress  to 
expeditiously  learn  everything  about  the 
new  environment  and  at  the  same  time  keep 
meeting  the  deadlines  of  the  malntenaee 
tasks  on  the  outgoing  environment. 

I£A5IflI£IXi  £ L  I£A££IAfl  AHA  Xfl  £££££ 

F10Q1AHMEBS  EFFICIEHTLI 

Designers  and  programmers  in  the 
COBOL  environment  have  been  using 
structured  design  techniques  like  those  of 
Xourdon  and  Constantine  Cl].  These 
software  developers  have  been  practicing 
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Modular  design  with  enphasls  on  uncoupled 
or  loosely  oouplod  noduloa  with  functional 
cohesion  (see,  ror  exanple 
Yourdon/Conatant lne  ( 1 ,  pages  8A-H0)  aa 
lnportant  criteria  ror  the  goodness  of 
doalgn.  Thaao  eoneopta  of  coupling  and 
oohoalon  art  strongly  llnkod  to  tho 
software  engineering  prlnelpala  of 
nodularity,  locallaatlon,  hiding,  ar.d 
abatraetlon.  Ada  aupporta  thoaa 
prlnolploa  vary  atrongly.  Katurally, 
aoaaonod  progrannara  of  COBOL  can  laarn 
Ada  and  Make  thla  learning  enjoyable  by 
capitalising  on  their  experience  ulth  good 
dealgn  practices. 

One  can  alao  achieve  efficiency  and 
productivity  gains  In  the  Ada  training 
prograa  for  the  olaaa  of  seasoned  COBOL 
progrannera  by  aapitalltlng  on  the 
experlenoe  and  understanding  of  these 
progranners  with  the  data  structures, 
control  structures,  nodule  structures,  and 
the  good  design  principles  practiced  when 
they  used  COBOL. 

Several  organisations  in  the 
Departnent  of  Defense,  where  the  use  of 
Ada  has  been  Mandated,  have  nany 


progrannera  with  experlenoe  in  COBOL 
progressing  language.  Capitalising  on 
this  experience  in  the  training  progran 
for  Ada  can  be  very  useful  in  increasing 
the  productivity  of  the  training  progran, 
and  alao  in  reduolng  the  front-end  cost  of 
the  change  in  the  language  standard  at 
these  organisations.. 

uiLiu  isu  xx  xumxfi  mm  axeaxa 

LilSfiAU 

Arthur  Jones  et  al  (2)  have 
investigated  the  feasibility  of  a  CAX  tool 
for  transitioning  COBOL  progrannera  to 
Ada.  This  Ada  CAI  tool  uses  analogy  to 
nake  learning  sore  efficient.  It  attenpts 
to  explain  Ada  oonoepta  and  techniques  in 
terns  of  COBOL  analogues. 

Agrawcl  and  Hllburn  [3)  have  proposed 
that  *The  benefits  of  the  reverse 
engineering  process  oan  be  realised  if  the 
redeaign  tcaa  has  education  in  both  the 
language  in  whloh  the  aysten  was 
originally  lnplenented,  and  in  Ada,  the 
language  of  ohoioe  for  the  iaplenentatlon 
of  the  new  redesign.  Therefore,  there  is 
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aerlt  in  educating  aeabera  of  euoh 
redealgn/lapleaentatlon  i«ui  In  Ada  »•  a 
aeoond  language." 

Beeauae  of  the  laportvooe  of  Abatraet 
Data  Typea,  and  Abairaotlon,  it  la 
important  to  anphaaisa  tbaaa  topioa.  Tha 
knowledge  of  COBOL  D*  ta  Struoturaa, 
Control  Struoturaa,  and  Module  Struoturaa 
oan  ba  uaad  to  lntroduoa  Ada  atandarda  on 
thaaa  toplea.  Vida  aoeaptanoa  of  COBOL  85 
(ana,  a.g.,  Jarona  Qarfunkel  (ID])  haa 
lnoraaaad  tha  nuaber  o f  auoh  Ada-COBOL 
parallal  oonatruota  on  tha  above  aantlonad 
atruoturaa.  Taaohlng  aodulea  that 
oapltallsa  on  thaaa  Ada-COBOL  parallal 
oonatruota  ara  llkaly  to  algnlf loantly 
lnoraaaa  tha  auooaaa  rata  of  taaohlng  Ada 
to  COBOL  prograaaara.  Thla  paper 
propoaaa  a  fraaawork  for  a  oouraa  to  taaoh 
Ada  to  COBOL  prograaaara  oapltalialng  on 
tha  prior  axparlanaa  of  COBOL  prograaaara. 

mammies  m  teachibq  m  in  cm 

PBOOBAHHEBS 

Experienced  COBOL  prograaaara  already 
ha va  baan  practioing  atruoturad 


prograaalng  technlquea  alnoa  tha  lata 
aavantlaa  (ana,  a.g.,  Tylar  Walburn  (*))• 
Therefore,  for  tha  aalaol  olaaa  of  people 
^  i  ^)|y |  i  n  j  | (j (j  (txpiriiRQi^  COBOL 
pro|r**»*ri),  wi  can  prtaua*  knovl«dc«  of 
atruoturad  prograaalng  teohnlquea  and  need 
to  atata  thla  aaauaptlon  aa  *a 
preraquialte  for  tha  propoaad  oouraa. 
Infect,  we  need  tc  atata  all  tha 
aaauaptlona  baa.  ,  aada  about  the  olaaa  of 
atudanta  who  are  expeoted  to  take  thla 
oouraa: 

1.  Studanta  ahould  have  raaaonabla 
axparlunoa  of  prograaalng  In  COBOL,  and 
alao  ba  faalllar  with  tha  COBOL  85 
atandard  (5). 

2.  Studanta  ahould  ba  faalllar  with  aodarn 

prograa  daalgn  teohnlquea  (atruoturad 

oodlng,  top-down  daalgn,  atepwlea 
raflnaaent,  eto.). 

3.  Studanta  ahould  have  aoaa  exparlanoa 

with  problea  aolvlng  oouraea  (a.g. 

aath  or  aoienoe  oouraea)  or  ooaputer 
prograaalng  exparlanoa  beyond  a  aingle 
oouraa. 
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The  fr»« 


xmjuul  HIM 


K  for  this  ooun«  la 
being  developed  ,bi»  paper  for  tha  non- 
tradltlonal  student  who  la  an  experienced 
COBOL  prograaaer  and  therefore  easily 
aatlaflaa  the  above  prerequisites,  or  oan 
acquire  then  quickly  b>  self  raading  or 
through  a  guided  study  of  thaaa 
praraqulaltaa. 

OBJECTIVES  ££  Utf  UQlSOtlL  ffillil 
Tha  learning  objectives  of  tha  course 

ara: 

a.  Study  and  praotloa  of  tha  baalo 
faaturaa  of  tha  Ada  programing  languaga; 
ualng  coaparlaon  and  oontraat  with  COBOL. 
Eduoatora  will  naad  to  davalop  datallad 
tablaa  of  aoaparlson  and  oontraat  of  tha 
faaturaa  of  Ada  varaua  thoaa  of  COBOL  85. 
Soae  exaaples  appear  In  tha  following 
aaotlona  of  thla  papar. 

b.  Use  of  paokagaa  and  their  support  for 
aodularlty  and  localisation)  and  their 
aupport  for  tha  davalopaant  of  reuaable, 
«aay  to  aaintaln  prograa  units; 

o.  Tha  various  Ada  features  that  support 
abstraction  and  lnforaatlon  hiding. 


Iti  the  topical  outline  below, 
frequent  rafaranoa  haa  bean  wade  to  tha 
Languaga  Reference  Manual  (LRM)  or  tha 
Rafaranoa  Manual  for  tha  Ada  Programing 

Languaga. 


1.  INTRODUCTION  (6  hours) 

a.  history  of  tha  davalopaant  of  Ada 

b.  structured  prograa  design  and 
pseudocode  prograaalng 

o.  software  engineering  and  tha 
principal  features  of  Ada 

d.  ooaaonalty  of  goals  of  struoturad 
prograa  daalgn  and  software 
engineering  and  early  exposure  of 
the  Ada  features  that  support  these 
goals. 

2.  BASIC  ADA  CONCEPTS  (10  hours) 

a.  Predefined  types  -  •  BOOLEAN, 
CHAa„CTER,  INTEOER,  ENUMERATION, 
BOOLEAN,  and  REAL.  (LRM  Chapter  3) 

b.  oontext  clauses  and  Instantiation 
of  genarlo  paokages  In  text_lo,  and 
exposure  to  the  paokaga  standard 
(LRM  7.1,  8. A,  10.1,  10.1.1) 

c.  structure  of  an  Ada  prograa 
declaration  part  and  execution  part 
declarative  region,  aoope  of 
declaration,  visibility,  executable 
stateaents  (LRM  3.1,  8.1,  8.2,  8.3, 
and  5.1) 

d.  input/output  (LRM  1A.3,  I*. 3.1  - 

14.3. 10,  and  14.4) 

e.  an  Ada  ooapller  and  its  environaent 
(LRM  10.1,  10. A,  10.5) 

3.  OPERATORS  AND  CONTROL  STRUCTURES  IN  ADA 

VERSUS  COBOL  85  (6  hours) 


7th  Annual  National  Conference  on  Ada  Technology  1989  299 


7.  ADVANCED  TTPES  (3  hour*) 


*.  «xpr«**lona  (LRM  A. A) 

b.  control  itruoiuru  -  If,  eaae, 
loop,  goto  (LRH  chapter  5} 

A.  DATA  STRUCTURES  (8  hour*) 

a.  attributes,  subtypes,  derived 

types,  conversion  between 
type*  (LRM  A.1.A,  3.3.1,  3.3.2, 

3.3.3,  3. A,  and  A. 6) 

b.  enumerated  data  type*  (LRH  3*5.1, 

3.3,  3.3.1,  3.5,  3.5.1) 

o.  array*  and  strings  (LRH  3.3,  3.5, 

3.7.2,  A. 6,  3.6.3,  A. 2) 

d*  r  3  o  o  rd  a  (LRH  3.3,  3*3.1,  3*7, 

3.7.A) 

e.  file*  (LRH  ohapter  1A) 

5.  SUBPROGRAHS  IN  ADA  VERSUS  COBOL  85  (6 
hours) 

a.  functions  and  procedures  (LRH  6.1, 
6. A,  6.5) 

b.  operators  and  overloading  (LRH  A. A, 
A. 5,  8.3,  8.7) 

o.  recursion  (LRH  6.1,  6.3.2,  12.1) 

6.  PACKAGES  (5  hours) 

a.  specification  and  body  (LRH  7.2, 
7.3) 

b.  visibility  and  soope  (LRH  8.2,  8.3) 

o.  library  units  and  order  of 
coaipllatlon  (LRK  chapter  10) 

d.  generlo  units  (LRH  chapter  12) 

e.  Ada  compilation  units,  library 

units,  order  of  ooapilation, 
program  library,  and  elaboration  of 
library  units  (LRH  10.1,  10.1.2, 

10.2,  10.2.1,  10.3,  10. A,  10.5) 


a.  aooeaa  types  (LRH  3.3,  3*8) 

b.  variant  part*  (LRH  3.7*3,  A. 1.3) 

c.  private  types  (LRH  3*3,  7. A) 

8.  TASKS  (5  hours)  (LRH  chapter  9) 

a.  real  time  application*  in  data 
processing  and  concurrent 
programming 

b.  tasks  and  rendoavoua 

o.  taak  type* 

10.  HISCELLANEOUS  ADA  TOPICS  (3  hours) 

a.  exception  handling  (LRH  ohapter  11) 

b.  implementation  dependent  features 
(LRH  chapter  13,  and  vendor 
supplied  LRH'*  Appendix  F) 

c.  support  available  in  the  Ada  community 

d.  trends  and  conclusions 


USEFUL  CflmilSflMfi  EAA  IH£  COURSE 


control  sxaucmass  in  com  is  ahu.  aha 


1.  If  Structures 

Ada:  if  <oondltlon>  then 

<s_o_s>* 

(  elslf  <oondition>  then 
<s_o_a>  ) 

(  else 

<s_of_s>  ) 
end  if; 

COBOL  85:  IF  <oondltion> 

THEN  <s_o_s> 

{  ELSE  IF  <oondition> 
THEN  <s_o_s>  ) 

{  ELSE  <s_o_s>  ) 
END-IF. 

•  s_o_8  s>  sequenoe_of  .statements 
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module  filEUCTUISS  It  MuiUfiA 

Syatea  aalntananoa  la  a  natural 
event.  Accepting  thla  baslo  faot,  It  la 
Important  to  daalgn  ayataaa  with  tha 
aalntananoa  funotlon  in  wind.  Thla 
philosophy  haa  baan  a  driving  foroa  In 
aatabllahlng  MAjUIlAtilltX  AAd 
undaratandabll ltv  aa  two  of  tha  four  goala 
of  aoftwara  anglnaarlng  for  tha  praotloa 
of  all  prograaaers  aa  propoaad  by  Boss, 
Ooodanough  and  Xrvlna  [7)  ar,d  Boooh  [3], 

Poorly  atruoturad  and  poorly 
doouaantad  ayataaa  davalopad  in  COBOL  In 
tha  sixties  or  tha  aarly  aavantlaa  ara 
faat  raaohlng  thalr  obaolaaoanoa.  Hany  of 
thaaa  obaolata  ayataaa  ara  ao  out  of 
control  that  thay  hava  to  ba  dlaoardad  and 
raplaoad  with  ooaplataly  naw  ayataaa. 

Fundaaantal  thaoraa  of  aoftwara 
anglnaarlng  propoaad  by  Tourdon  and 
Conatantlna  [1]: 

C(P/2)  ♦  C( P/2)  <  C(P) 
pointa  out  that  tha  coaplaxity  of  a 
problaa  oan  ba  raduoad  by  dividing  tha 
problaa  Into  aavaral  aaaller  problaaa. 
Daooapoaition  of  a  funotlon  Into  ooaponant 


aubfunotiona  la  tha  tool  for  aahiavlng  tha 
aoftwara  anglnaarlng  goal  of  nodularity 
[7).  COBOL  prao t 1 t Iona r a  hava  baan 
praotlolng  It  for  aona  tlaa  now  and 
parhapa  would  walooaa  aany  faaturaa  In  Ada 
that  ara  not  avallabla  In  COBOL  85»  but 
thaaa  faaturaa  anforca  nodularity 
prlnelpla. 

Exaaplaa  of  aodulaa  lnoluda 
procedures,  subroutines,  and  funotlona. 
Modularization  allowa  tha  daalgnar  to 
dacoapoaa  a  ayataa  into  functional  unlta, 
and  iapoaa  hiararohloal  ordering  on 
funotlon  uaaga,  aa  wall  aa  laplaaent  data 
abstraction,  whioh  Ada  allowa  wore  than 
COBOL  85.  An  iaportant  aoftwara 
daalgn  objective  la  to  atruotura  tha 
aoftwara  product  ao  that  tha  nunber  and 
coaplaxity  of  lntaroonnactlona  between 
aodulaa  la  ainialzad.  Spaolal  rulaa  on 
aoopa  and  vlalblllty  within  and  outalda 
Ada  paokagea  give  tha  daalgnar  a  atrong 
control  on  the  lntaroonnaotlona.  Separata 
ooapilatlon  of  packagea  and  paokaga 
specification  and  package  body  also  give  a 
atrong  control  for  ainialzlng 
intaroonnectlons. 
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TEACHING  ADA  FROM  THE  OUTSIDE-IN 


Donald  P.  Purdy 


Manatee  Community  College,  Bradenton,  Florida 


Aba  tract 

Teaching  Ada  from  the  outside-in  is  a 
concept  which  the  author  conceived  after 
attending  the  1980,  Department  of  Defense, 
Ada  Curriculum  Development  Seminar  held  at 
Tuskcgoo  University,  Alabama.  Tho  seminar 
members  agreed  that  tho  more  difficult 
topics  of  exception  handling,  tasking, 
real  tima  interfacing,  user  defined 
generics,  acc  ss  types  and  discriminant 
records  could  be  ignored  in  a  first  year 
Computer  Science  course  (CS-1).  The 
author  agreed  with  these  exclusions,  but 
felt  that  without  those  items,  the  true 
power  of  Ada  could  not  be  taught.  The 
outside-in  concept  was  designed  to  teach 
tho  basics  and  tho  advanced  subjects  in  a 
way  that  would  maintain  studont  interest 
while  they  worked  on  the  more  mundano 
aspects  of  the  language.  It  would  also 
lead  tho  studonts  into  using  the  advanced 
tool3  that  Ada  provides.  This  concept  was 
used  in  our  first  Introduction  To  Ada 
class  in  tho  Foil  of  1988. 


Methodology 

Tho  instructional  plan  included i 

1.  Developing  a  schodulo/syllobus  that 
would  allow  teaching  simple  and  complox 
subjects  at  tho  3amo  time. 

2.  Identifying  advanced  students  and 
neophytes  using  on  cxporionce  survey  form. 

3.  Scheduling  studonts  for  different 
class  hours  and  different  subjects 
depending  upon  their  oxporionce. 

4.  Using  videotapes  for  tho  simple  topics 
with  instructor  controlled,  tape  playback. 

5.  Using  an  overhead  and  detailed  program 
walk-thru  for  tho  advanced  subjects. 

G.  Getting  the  studonts  interest  and 
involvement  in  the  outsidc-in  concept 
during  the  first  class  meeting. 

7.  Maintaining  that  interest  by  showing 
beneficial  usage  of  tho  advanced  subjects. 


8.  Relating  advanced  subjects  to  sched¬ 
uled  course  topics  whenever  possible. 

9.  Developing  follow  up.  advanced  subject 
presentations,  by  expanding  or  refining 
the  applications  previously  used. 

10.  Maintaining  on  active  interest  in 
studont  programming  efforts. 


Student  Data 

Tho  student  survey  forms  produced  tho 
following  studont  data: 

Math  codes  indicate: 


0 

-  It. 

S.  Algebra 

3  - 

Clg  Calc 

I 

I 

-  Clg  Alg  I 

4  - 

Clg  Calc 

II 

2 

-  Clg  Alg  II 

5  - 

Clg  Calc 

III 

Stu  Wkg 

Language  Experience 

ID» 

Hrs 

Ada 

Panel 

com.  c 

FORT 

UAS 

Math 

1 

"52 

X 

X 

—  * 

~ 3_ 

2 

52 

X 

X 

X 

3 

3 

GS 

X 

X 

2 

4 

56 

X 

X 

X 

X 

2 

5 

45 

X 

X 

X 

X 

3 

6 

3G 

X 

X 

X 

X 

5 

7 

G9 

X 

X 

1 

8 

52 

X 

X 

1 

9 

GO 

X 

X 

2 

10 

52 

X 

X 

2 

11 

52 

X 

X 

3 

12 

52 

X 

X 

3 

13 

G2 

X 

X 

0 

14 

52 

X 

X 

3 

15 

52 

X 

X 

3 

1G 

48 

X 

X 

X 

X 

3 

Totals 

2 

12 

2  4 

9 

11 

Corrected  0 

7 

2  2 

9 

11 

Further  detailed  questions  in  class 
led  to  the  corrected  data  line.  The  two 
students,  who  had  indicated  Ada  experi¬ 
ence,  had  written  short,  20  lino  programs. 
Tho  Pascal  and  C  numbers  wore  revised  for 
a  like  reason.  The  Wkg  Hrs  column  figures 
are  based  on  a  combination  of  actual  work¬ 
ing  hours  plus  an  estimate  of  12  hours  of 
study  per  week  for  each  3  semester  hour 
course.  This  information  and  the  math 
data  are  used  to  identify  students  who  may 
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have  difficulty  completing  the  coucao  with 
o  satisfactory  grade.  This  class  had  a 
very  high  drop/fail  potential  considering 
the  working  hours  and  a  very  low  potential 
considering  the  math  data. 

The  corrected  data  indicate  an  almost 
equal  level  of  structured  language  experi¬ 
ence  and  non-structured  experience.  This 
class  make-up  was  almost  perfect  for  using 
tho  outside-in  approach.  The  students 
having  structured  experience  were  our  own 
Computer  Science  majors  who  chose  the 
course  as  an  advanced  elective.  One  of 
those  was  a  quadriplegic  with  almost  total 
motor  and  speech  impairment.  Most  of  the 
remaining  students  worked  for  a  local 
defense  contractor.  These  students  were 
very  difficult  to  guide,  and  wore  need¬ 
lessly  disruptive  during  tho  initial 
classes.  One  student,  salf-taught  in 
DASIC  and  Pascal,  worked  for  a  local  Form 
Credit  Bureau.  To  later  identify  a 
student  or  a  class  of  students  the 
following  codos  will  be  used: 

S  -  Structured  experience 
(Pascal,  Modula-2  4  C) 

N  -  Non-structured  experience 
(BASIC  4  FORTRAN) 

L  -  Low  math  experience 
(No  college  math) 

II  -  High  hour  schedule 
(Over  60  hours) 


Tho  Environment 

Eight  of  tho  students  did  their  work 
on  a  1983  validated  compiler  running  on  a 
VAX  11/750.  This  compiler  did  support 
generics.  Integor,  Float,  and  Boolean 
I/O  wore  handled  by  packages  nested  in  the 
Text_IO  package.  During  tho  latter  part 
of  tKa  semester,  the  company  these  stu¬ 
dents  worked  for,  locked  out  tho  student 
Ada  passwords  until  5  PM.  It  3ccms  the 
Ada  compile  runs  were  deteriorating  tho 
computer  production  capacity  during  daily 
backups.  The  rest  of  the  class  completed 
their  work  using  a  popular  microcomputer 
compilor  running  on  the  college  G40K,  hard 
drive  machines. 


The  Schedule 

Wk  Regular  Advanced 

No  Subject  Subject 

1  Introduction 

2  Names  In  Ada  Using  Ada 

Constants  &  for  Design 

Expressions  Instantiation 

3  Pro-defined  Types  Low_Lovel_IO 

(Class  3  was  canccllca  due-to  weather) 

4  Pre-defined  Types  Low_Level_IO 

User  Defined  Types  Exceptions 

5  Control  Structures  Tasks  &  Packages 


Schedulo  (Continued) 

Wk  Regular  Advanced 

No  Subject  Subjcet 

6  Arrays/Tost  II  Tasks  6  ODD* 

7  strings  4  Records  Task  Types 

8  Subprograms  Generic  Subprograms 

Recursive  Functions 

9  Generic  Subprograms  Generic  FIFO  Pkg7 
Packages 

10  Formatted  I/O  Discriminants 

Overloaded  Operators  Private  Type3 

11  Discriminont3/Testl2  Access  Types/Filos 

12  List  Processing 
Private  Typos 

13  Exceptions  and  Files 

14  Tasking 

(14  Cancelled  due  to  Tropical  Storm  Keith) 

15  Tasking,  Low_Lovol_IO  and 
Using  Ada  for  Design 

16  Review  4  Final  Exam 

The  schedule  was  altered  by  two 
weather  systems  wo  experienced  during  tho 
semester.  This  caused  doubling  up  on  some 
class  content,  but  at  tho  same  time  allow¬ 
ed  the  instructor  more  time  to  prepare 
concise,  direct,  mora  meaningful  presen¬ 
tations.  Wherever  possible,  tho  advancod 
subjects  wore  presented  so  as  to  improve 
upon  the  regular  subjects. 


Assignments 

Assignments,  two  per  chapter  through 
the  twolfth  chapter5,  wore  contained  in 
tho  course  syllabus.  Thi3  left  5  weeks  at 
the  end  of  the  course  for  work  on  tho  team 
projocts.  Tho  students  sot  up  their  own 
taams  with  the  instructors  approval. 
Approval  was  based  on  each  team  having  at 
leost  one  member  with  structured  program¬ 
ming  experience.  Each  team  was  allowed  to 
design  their  own  final  project  although 
they  were  3trongly  encouraged  to  dovolop  a 
cruise  missile  autopilot  program.  Most 
teams  opted  for  other  final  projects, 
claiming  insufficient  knowledge  of 
aerodynamics  or  flight  control  systems. 


Tcachor/Student /Subject  Interaction 

During  tho  first  two  classes,  the 
students  were  asked  to  confirm  their 
acceptance  of  and  participation  in  the 
outside-in  concept.  The  response  was 
positive  each  time.  Tho  third  class  was 
canceled  duo  to  severe  rainfall  and  local 
flooding.  Tho  advancod  subject  .?or  the 
fourth  class  was  real  time  interfacing,  a 
difficult  item,  especially  since  the 
compiler4  did  not  support,  the  subject.  As 
the  teacher  began  the  presentation,  the 
students  revolted.  They  had  not  prepared 
for  the  subject.  Learning  the  syntax  and 
style  of  Ada  plus  the  complex  features  was 
too  much.  At  this  point,  the  students  and 
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the  teacher  reached  a  compromise.  The 
presentation  o f  advanced  subjects  would 
continue,  but  the  students  would  only  be 
required  to  study  the  regularly  scheduled 
subjects. 

The  class  continued  with  real-time 
interfaces  presentation  followed  by  the 
regularly  scheduled  subject  and  then 
another  advanced  subjact,  exception 
handling.  Students  were  advised  that  they 
did  not  have  to  stay  for  advanced  subject 
presentations  for  this  class  or  any  other 
unless  they  desired.  It  is  interesting 
that  no  one  skipped  any  of  the  presenta¬ 
tions  on  advanced  subjects  oven  though 
they  were  given  the  opportunity.  Fear  of 
being  left  behind  may  have  been  the  cause. 
Student  involvement  was  the  very  high  dur¬ 
ing  coverage  of  advanced  subjects. 

Tasking  wa3  the  advanced  subject  for 
the  fifth.  Using  on  overhead  projector  to 
display  the  programs  and  the  output  (text 
and  float),  a  walk-thru  showed  the  program 
progression  mixed  with  task  actions.  The 
remaining  classes  were  conducted  using 
video  tapes  for  thu  simple  topics  and  an 
overhead  walk-thru  for  tha  advanced. 


In-Class  Participation 

Student  participation  ran  from  dis¬ 
belief  (exception  handling)  to  apprecia¬ 
tive  awe  (tasking  and  generics).  The  use 
of  packages  in  program  development  brought 
high  interest.  Controlled  playback  of  the 
instructional  topes  allowed  moro  timely 
and  pertinent  student  questions.  The 
overhead  presentations  of  advanced  topics 
evoked  high  student  involvement.  The 
students  could  proceed,  arguing  and 
discussing  tha  subjact,  with  the  instruc¬ 
tor  joining  in  at  points  where  clarifica¬ 
tion  or  on  opinion  was  required.  Thi3 
usually  fostered  further  discussion. 


Drop  Rate  ond  Causes 

A  12.5%  drop  rate  was  recorded  when 
two  of  the  sixteen  students  withdraw  from 
the  class.  Ono  of  these  students  was 
forced  to  miss  several  early  classes  due 
to  surgary/rocuporation.  The  second 
student  ( II13-N,L,II)  had  a  vary  high  drop 
potential  based  on  his  student  evaluation 
form.  Ills  dropping  proved  the  validity  of 
the  form.  Throo  students  wore  question¬ 
able  until  the  fifth  class  when  they  opted 
to  stay  on  board.  Thoso  were  all  N  typos. 


Problems  Encountered 

The  first  pr'"'  ',em  with  teaching  Ada 
is  the  genera)  >:  Ada  programming  mind¬ 


set.  That  is,  develop  useful  programs 
that  do  not  depend  on  or  support  any  other 
programs.  Tha  acceptance  of  reusable 
packagas  and  multi-use  generics  is  a 
small  hurdle  to  overcome.  The  second 
problem,  inbred  by  BASIC  and  FORTRAN,  is 
tha  tendency  to  be  terse  with  identifier 
names.  Tha  third  problem  i3  a  manifesta¬ 
tion  of  the  second.  Presentation  of 
complicated,  interrelated,  programming 
concepts  calls  for  judicious  use  of  media 
space.  This  may  lead  to  bad  exomplos  of 
solf-documenting  identifiers  or  the  use  of 
simplistic,  usoles3,  program  examples. 

The  first  problem  can  bo  overcome.  The 
second  and  third  will  require  some  work. 

A  problem  relevant  to  thi3  class  was  the 
use  of  two  different  compilers.  The  older 
version  had  fully  defined  I/O  packages  for 
Integer,  Float,  and  Boolean  types.  The 
newer  model  roquired  instantiation  of 
genoric  I/O  packagas  for  these  types. 


Conclusion 

The  outside-in  approach  obtained  good 
results  using  early  introduction  of,  and 
student  involvement  in,  the  advanced  and 
more  interesting  aspects  of  Ada.  Early 
discussion  of  advanced  topics  made  later 
coverage  moro  meaningful.  When  the  topic 
was  revisited,  studont  participation  wa3 
more  intense  resulting  in  grantor  under¬ 
standing  of  the  subject.  The  concept 
worked  well  with  this  particular  group: 
however,  testing  i3  needed  on  a  CS-1  class 
where  most  of  the  students  ore  first  year 
Computer  Science  majors. 
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ABSTRACT 

The  DoD  expected  the  Ada  language  to  be  a  solution 
to  spiraling  software  costs.  However,  the 
development  ol  a  tool  and  the  proper  use  oi  tire  tool 
are  not  the  same.  DoD  understood  that  realizing 
these  cost  savings  would  depend  (among  other 
things)  on  rigorous  training  in  the  correct  use  ol  tire 
tool.  Improper  or  Inadequate  training  In  this  language 
tool  will  produce  code  which  accomplishes  nono  ol 
its  goals  and  costs  more  to  write.  From  experience  K 
seems  that  the  longer  a  person  has  been  hi  the 
industry,  the  longer  it  will  take  lor  him  to  learn  this 
new  language  because  previous  languages  required 
the  problem  to  be  Implemented  from  the  hardware 
perspective.  Since  Ada  views  the  problem  differently, 
retraining  of  experienced  personnel  is  needed.  A 
solution  to  the  dilemma  can  be  found  hi  the  student 
exercises  which  support  the  course  work.  This 
means  that  the  problem  set  must  be  designed  for 
experienced  personnel  but  could  be  used  for  otlters. 


INTRODUCTION 

Experienced  programmers  have  responded  to  the 
proliferation  of  programming  languages  developed 
over  the  last  30  years  with  minimal  difficulty. 
Instruction  in  these  languages  has  been  a  syntactic 
presentation  given  in  a  relatively  brief  time  period, 
and  the  learning  curve  has  been  excellent.  This  Is  not 
the  case  with  Ada.  The  time  to  learn  to  use  this 
language  tool  effectively  seems  to  vary  in  direct 
proportion  to  the  years  of  programming  experience. 
This  presents  a  tremendous  dilemma  to  management 
who  find  the  increase  in  training  costs  difficult  to 
accept  and  to  the  student  who  is  accustomed  to 
learning  new  languages  with  relative  ease.  It  is 
essential  to  develop  a  curriculum  that  solves  this 
problem  because  without  successful  adaptation  to 
the  the  new  language,  the  goals  for  which  it  was 
designed  will  never  be  realized.  In  particular  the 
costs  of  implementing  in  this  language  will  be  more 
rather  than  less. 


OBJECTIVES  OF  THE  COURSE 


The  Ada  language  is  large  and  contains  many  difficult 
and  subtle  features.  Subsetting  of  the  language  is  not 
an  acceptable  approach.  In  fact  the  foliowing  issues 
must  be  addressed: 

1.  The  student  must  not  only  be  exposed  to 
the  entire  language  as  specified  in  MIL- 
STD-1815A  but  must  also  develop 
expertise  In  which  he  can  select 
appropriate  features  of  the  language  for 
Implementation  in  different  circumstances. 

2.  A  rigorous  style  convention  must  be 
adapted  or  the  wordiness  ol  tlie  tool  will 
discourage  the  coder. 

3.  Available  tools  (language  sensitive  editors 
and  debuggers)  must  be  used  by  the 
student. 

None  of  this  is  possible  unless  a  firm  foundation  has 
been  laid  prior  to  hands-on  exposure  which 
addresses  the  software  engineering  principles  that 
are  realized  in  Ada  by  using  the  following: 

1.  Abstraction 

2.  Information  hiding 

3.  Data  encapsultation 

4.  Reusable  components 

5.  Fault  Jolerant  processing 

SELECTION  OF  A  PROBLEM  SET 


The  development  of  a  probtem  set  (not  a  ca.se  study) 
which  will: 

1 .  Allow  the  student  to  utilize  many  Ada 
features 

2.  Demonstrate  to  the  student  the 
appropriateness  of  each  feature 
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will  help  the  retraining  effort  to  achieve  an  effective 
technology  transfer.  Each  problem  in  the  sot  should 
Include  a  template  that  can  be  copied  and  a  set  ol 
Instructions  explaining  the  requirements.  Those 
should  focus  on  very  specific  aspects  of  the  language 
Including: 

1 .  Text  JO  versus  FileJO 

2.  UseClauses 

3.  Attributes 

A.  Records  with  Discriminants 

5.  Derived  and  Subtypes 

6.  Abstract  Oata  Types 

7.  Packages-Specilication  and  Body 
Q.  Access  Types 

9.  Input/Output  and  Implementation 
Dependence 

10.  Use  of  tools 

11.  Private  types 

Individual  problems  are  chosen  instead  of  a  case 
study  because  system  experience  gained  from  a 
case  study  approach  is  not  the  objective  here.  The 
objective  is  to  learn  to  use  Ada  language  features 
correctly. 

PREREQUISITES 

At  the  beginning  of  this  course  the  student  has 
received  a  foundation  in  the  Ada  languague  and  has 
completed  a  minimal  set  of  Ada  problems  and  is  able 
to 

1 .  Creoto  on  Ado  program  library 

2.  Write  a  procedure,  function  and  package 
private  types 

3.  Use  attributes,  user  defined  types  and 
private  types 

A.  Combine  program  units  by  way  of  a 
context  clause 

5.  Instantiate  generics  to  do  integer  and 
enumeration 

Input/Output 

6.  Compile,  link  and  run  an  Ada  program 

Now  the  students  Is  ready  to  become  an  Ada 
programmer. 

In  the  following  exercises  it  is  assumed  that  the  VAX 
Ada  Compiler  and  the  VAX  Ada  program  library 
manager(ASC)  are  used,  but  any  Ada  development 
environment  can  be  used. 


INTERACTIVE  PROCESSING  AND 
IMPLEMENTATION  DEPENDENCIES 

Input/Output  is  so  difficult  In  most  languages  that 
usually  only  a  few  people  know  how  it  really  works. 

In  Ada.  a  reusable  package  has  been  provided  and 
everyone  con  write  I/O.  However,  the  student  must 
overcome  his  natural  fear  of  this  subject  and  also 
learn  about  certain  Implementation  specific  problems 
which  must  be  overcome  to  achieve  reusability.  This 
topic  provides  an  excellent  opportunity  to  learn  about 
reusability,  Its  advantages  and  limitations,  by  writing 
I/O  code. 

In  tire  preliminary  problem  set.  the  student  has 
initialized  all  of  the  variables  within  the  program  so 
that  Ire  would  not  have  to  be  confused  with 
Input/Output.  He  has  been  required  to  write  only 
Text  JO  'Put'  statements.  These  were  needed  to 
demonstrate  tire  correctness  of  the  programs.  The 
first  problem  in  this  course  requires  that  one  of  the 
preliminary  problems  be  rewritten  so  that  data  can  be 
entered  Interactively  from  the  terminal.  The  problem 
asks  for  a  count  of  the  number  of  non-blank 
characters  In  any  string  entered  from  the  terminal. 

The  solution  is  facilitated  by  the  use  of 
TextJO.GetJJne.  Some  insight  is  needed  to 
implement  this: 

1 .  A  string  object  must  be  initialized  to  all 
blanks. 

2.  A  constraint  for  the  length  of  the  string  Is 
required.  (This  limits  the  length  of  the 
string  entered  from  the  terminal.  The 
program  should  Inform  the  user  of  this  with 
a  prompt.) 

Since  the  parameter  list  for  TextJO.GetJJne  is 
defined  as 

(Item:  out  String;  Last:  out  Natural); 

Several  limitations  appear: 

1 .  If  the  actual  parameter  which  matches 
LAST  is  of  type  Positive  (a  subtype  of 
Natural),  an  accidental  depression  of  the 
carriage  return  at  the  terminal  will  cause  a 
constraint  error  because  a  value  of  zero 
will  be  returned  for  LAST  and  that  value 
does  not  exist  for  Positive(range 
constraints). 

2.  If  the  user  wants  to  constrain  the  string  to 
be  very  long  and  does  this  by  defining  the 
string  as  1..Positive'Last(in  agreement  with 
the  LRM)  a  numeric/constraint  error  will  be 
raised  because  the  size  of  strings  on  Dec's 
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Vax  are  limited  to  65,000  (implementation 
dependency). 

3.  If  Ute  size  of  the  string  is  constrained  by  a 
constant,  that  constant  must  be  of  type 
Positive  or  some  subtype  thereof  to  match 
the  string  constraint  in  package  standard. 

It  must  not  be  a  derived  typo  (strong 
typing). 

Problem  2  continues  with  more  opportunities  to 
experience  input/ootput  and  an  introduction  to  the 
'use*  clause.  The  student  prefers  to  use  the  'use' 
clause  because  it  reduces  tlie  amount  of  code  that 
must  be  written.  Ada  is  a  very  wordy  language  and 
this  is  annoying  to  the  new  user.  Since  ttve  student 
has  been  told  that  it  is  not  good  style  to  use  the  'use' 
clause  he  must  have  an  opportunity  to  understand 
the  confusion  that  can  result  from  Hs  use  and  misuse. 
Once  he  has  successfully  implemented  tho  problem 
whlKHJt  the  'use'  clause  a  change  Is  made  which 
results  In  an  error  condition  which  can  be  solved  with 
tlie  'use'  clause.  Tlie  complexity  of  the  language  is 
such  that  many  aspects  of  a  feature  need  to  be 
demonstrated.  As  with  some  of  the  other  problems, 
additional  Ada  features  are  utilized  in  the  solution. 

This  is  an  inventory  maintenance  example  wtrere 
quantities  of  liquor  are  stored  in  a  sequential  file.  The 
Information  for  each  'record'  includes  tlie  type, 
manufacturer,  quantity,  unit  price,  and  value.  These 
data  values  are  entered  interactively  from  the  terminal 
and  upon  a  request  from  the  user  the  program  will 
produce  a  total  inventory  value  broken  down  by  item. 

The  student  is  exposed  to  the  following  Ada 
concepts: 

1.  Text  JO 

2.  Sequential  JO 

3.  Records 

4.  Instantiation  ol  generic  units 

5.  Mixed  types 

6.  Use  clause 

7.  Exceptions 

In  addition  the  student  must  mail  the  teacher  the 
Inventory  file  in  readable  form.  The  student  must 
read  data  of  different  types  from  the  terminal,  store 
the  data  in  a  sequential  file,  make  calculations  on  the 
data  In  the  file  and  translate  the  sequential  file  back  to 
an  ASCII  file. 

Furthermore  the  10  Exceptions  can  raise  many  errors 
so  exception  handlers  must  be  written.  One  of  the 
errors  that  becomes  apparent  is  that  strings  are  case 
sensitive  and  fixed  length.  The  user  must  know  to 
blank  pad  the  string  that  is  entered  to  match  the 


constraint  in  the  definition.  Also  if  you  inquire  from 
the  user  as  to  whether  the  sesssion  should  be 
terminated.  YES  or  NO  and  the  response  is  No.  an 
error  will  occur  for  two  reasons,  the  length  of  the 
string  doesn't  match  and  the  case  doesn't  match. 

Oilier  things  that  will  be  learned  about  I/O  Include  tlie 
difference  between  Open  and  Create  and  tlie  uso  of 
file  mode.  Certain  implementation  dependencies 
such  as  when  the  end  of  lino  terminator  is  read  may 
also  be  discovered. 


In  addition,  this  problem  Is  designed  so  that  students 
with  different  capabilities  esn  be  challenged.  A  simplo 
solution  is  acceptable  but  a  moro  elegant  solution  will 
appeal  to  the  more  knowledgable  student. 

Wlien  this  problem  has  been  submitted  correctly,  a 
change  in  tlie  specification  is  made.  Now  all  tho  data 
types  for  the  records  must  be  encapsulated  into  a 
package  and  then  the  problem  Is  to  be  recompt'ed, 
relinked,  and  rerun.  If  any  ol  the  types  in  the  package 
were  derived  types  (and  at  least  one  of  tliem  should 
be  since  some  of  tlie  types  are  of  type  Float  from 
Package  Standard  and  it  is  recommended  to  make  a 
derived  type  of  Float)  on  error  occurs  because  of  tlie 
hiding  of  the  operators  in  tho  now  package  by  the 
operators  that  are  visible  in  package  Standard  in  tlie 
main  procedure  (see  N.CoherV'Ada  As  A  Second 
Language")*!.  Without  the  use  clause,  the  solution  to 
do  this  is  very  awkward.  Tlie  studont  has  a  choice  of: 

1 .  Using  selected  component  notation  for  on 
operator 

2.  Renaming  the  operator  function . (L.R: 

Liquor_Data_Package.Quantity. 

Liquor,  Data_Package.Price)  return 
Liquor.Data_Package.lnv  Value  renames 
Liquor_Data~Packnge."  *  "; 

3.  Inserting  tho  'use'  clause  for  the 
Llquor_Data_Packago  and  clearly 
commenting  why  it  has  been  added.  In 
addition  all  the  expanded  names  which 
have  been  Included  when  the  'use'  clause 
was  not  there  should  remain  in  place.  A 
final  touch  to  this  problem  to  guarantee  the 
use  of  a  style  convention  is  to  submit  the 
source  to  tho  Ada  repository  "pretty 
printer"  program.  The  student  must  be 
sure  the  result  is  copied  to  a  new  file  in 
case  the  changes  made  by  the  pretty 
printer  are  not  acceptable. 

A  final  touch  to  this  problem  to  guarantee  the  use  of  a 
style  convention  is  to  submit  the  source  to  the  Ada 
repository  "pretty  printer"  program.  The  student 
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most  be  sure  the  result  is  copied  to  a  new  file  In  case 
the  changes  made  by  the  pretty  printer  are  not 
acceptable. 


USING  THE  DEBUGGER  AND  DATA 
STRUCTURES  WITH  COMPOSITE  TYPES 


The  next  two  problems  are  to  be  compiled,  linked 
and  run  under  Debug.  The  student  has  received 
instruction  on  tiow  to  use  the  debugger  and  has 
completed  a  trivial  exercise  which  allowed  him  to 
practice  with  the  debugger. 

Ada  has  an  excellent  capability  (or  modelling  data 
with  composite  types.  However,  the  syntax  to 
Implement  these  structures  can  be  rather  confusing. 
Even  the  experienced  programmer  finds  these 
structures  difficult  to  implement.  These  problems  are 
included  to  force  the  student  to  practice  with  these 
constructs  and  become  comfortable  with  tliem. 

The  two  problems: 

1 .  Building  on  atlas  using  nested  records  and 
arrays 

2.  Building  a  variable  record  using  nested 
records  with  discriminants 

were  designed  to  provide  experience  in  how  to 
Implement  these  structures  so  that  in  a  real-world 
situation  the  student  will  not  be  afraid,  for  lack  of 
understanding,  to  take  advantage  of  this  rich 
expressive  capability. 

Problem  3  for  nested  records  and  arrays  requires 
five  type  definitions  to  create  an  array  of  records 
where  one  of  the  record  components  Is  an  array  of 
arrays  and  the  Inner  array  contains  records.  This  is 
not  a  trivial  exercise.  The  difficulty  is  In  accessing 
some  of  the  deeply  nested  components.  Running  the 
program  under  the  debugger  makes  this  easier  to 
understand.  However,  the  student  now  discovers 
some  limitations  in  the  VAX  debugger  as  it  supports 
the  Ada  language.  Arrays  of  records  with  four  fields 
are  not  supported.  If  an  'examine'  is  done  of  such  a 
structure  H  will  be  found  that  the  third  and  fourth  fields 
receive  the  same  default  value  for  all  of  the 
aggregates  even  though  an  Ada  'Put'  statement 
(using  Text  JO)  shows  the  aggregate  values  that  are 
expected.  No  warning  or  error  message  is  given  so 
the  novice  may  think  an  error  exists  in  the  program 
(using  the  debugger)  when  in  fact  no  error  is  there. 

In  addition,  when  defining  deeply  nested  composite 
types  it  is  easy  to  raise  a  storage  error.  The  student 


sliould  try  each  type  before  embedding  h  to  be  sure  H 
is  impiemcntable. 

Problem  4  on  discriminants  requires  a  description  of 
boats  where  boats  can  be  of  two  classes,  sailboats  or 
motorboats,  and  sailboats  contain  two  subclasses. 

All  of  the  boats  have  some  components  In  common. 
Tlie  first  dess  of  boats  also  has  some  new  unique 
components.  In  the  second  class,  both  subclasses 
have  some  components  In  common  but  also  have 
some  unique  components. 


There  ore  three  solutions  to  this  problem.  Tire  correct 
solution  is  the  one  In  which  a  component  of  the 
record  with  the  discriminant  is  itself  a  record  with  a 
discriminant.  The  outer  most  record  contains  a 
discriminant  that  shapes  the  record  as  a  motorboat 
or  a  sailboat.  The  components  that  ere  common  to 
all  boats  are  listed  and  then  the  variant  part  describes 
the  components  which  are  unique  to  sailboats  end 
motorboats.  For  a  sailboat  (lie  component  names 
anotlier  variant  part  which  allows  the  shape  to  model 
a  schooner  or  a  ketch.  The  other  two  solutions: 

1 .  Creating  two  discriminants 

2.  Renaming  equivalent  components 

do  not  result  In  very  well  defined  structures.  Creation 
of  two  discriminants  requires  a  null  value  for  one  of 
die  three  kinds  of  boats  which  does  not  use  the 
second  discriminant  and  renaming  equivalent 
components  is  not  good  modelling.  This  problem 
demonstrates  to  the  student  the  difficulty  of  using  this 
feature  without  abusing  some  of  the  languages 
objectives(i.e.  readability).  It  also  shows  the  student 
an  excellent  modeling  technique-nested  variant 
records-whicli  may  not  have  been  Intuitive. 


DEVELOPING  ABSTRACT  DATA  TYPES  AND 
CONSIDERING  APT'S  AS  CANDIDATES  FOR 
GENERIC  PROGRAM  UNITS 


An  abstract  data  type  (ADT)  can  be  defined  as  a  data 
type  with  a  set  of  operations  valid  for  that  type. 
Abstract  data  types  involve  the  following  three 
concepts: 

1.  Abstraction-extraction  and  presentation  of 
the  essential  properties  of  a  data  type 

2.  Information  Hiding-making  inaccessible  all 
implementation  details  of  a  data  type 

3.  Encapsulation-grouping  together  the 
various  details  of  a  data  type  abstraction 
and  its  implementation 
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These  concepts  we  supported  In  Ada  by  die 
following  feafuros: 

1.  Private  types 

2.  Limited  private  types 

3.  Package?  with  private  parts 

AOT's  we  naturally  implemented  in  Ada  and  tvetp  to 
enforce  many  of  tire  language  goals  such  os 
readability,  reusability,  and  maintainability.  Tire 
experienced  programmer  probably  has  never  worked 
with  ADT’s  since  he  has  probably  never  built  user 
defined  types.  The  uso  of  them  is  not  intuitive  and  if 
the  Ada  language  is  to  be  used  to  its  full  advantage,  H 
is  essential  that  ttre  student  understand  what  ttrey  are 
and  (row  to  implement  them.  Problem  5  addresses 
ail  tlrese  things  by  building  an  ADT  for  sets  and  using 
the  AOT  to  solve  a  problem  which  requires  the 
generation  of  4  sets.  The  set  universe  which  is  to  be 
Implemented  Is  tire  universe  of  integers  from  t  to  100. 
Tire  application  requires  tire  computation  of  tire 
following  four  sets: 

1 .  Set  divisible  by  2.3.or  5 

2.  Set  divisible  by  2  or  3  but  not  5 

3.  Set  divisible  by  3  and  5 

4.  Set  not  divisible  by  3 

The  solution  for  this  application  requires  tire  creation 
of  an  ADT  wfrere  the  universe  is  defined  to  be  an 
wroy  of  Booleans  and  the  wray  Is  irrdoxed  by  a 
subset  of  Integers  constrained  by  1  to  100.  This  array 
should  be  of  type  private  so  that  the  abstraction  will 
be  enforced  and  tlrerefore  H  must  be  encapsulated  in 
a  package  with  all  of  the  set  operations.  The 
implementation  of  those  operations  are  hidden  in  the 
package  body.  It  is  useful  when  implementing  an 
ADT  for  sets  to  declwe  two  constants,  one  for  the 
universe  and  one  for  the  empty  set.  Since  ttre  type 
which  models  the  universe  is  private,  it  will  bo 
necessary  for  ttre  student  to  use  deferred  constants 
It  will  probably  be  the  first  time  the  student  has  had 
the  need  to  use  tlrem  and  therefore  it  is  the  first  time 
Ire  will  understand  their  need  and  syntax.  Deferred 
type  definitions  will  be  needed  when  access  types  are 
introduced  so  this  Is  an  important  idea  to  develop. 

Not  all  of  the  possible  set  operations  are  required  to 
solve  this  problem  but  they  should  oil  be  Included  In 
the  package  because  it  becomes  a  candidate  for  a 
reusable  component.  In  fact  when  the  problem  has 
been  successfully  completed  the  student  should  go 
back  and  rewrite  the  package  as  a  generic.  The 
formal  type  parameter  should  be  defined  as  (<  >), 
that  is  it  should  be  capable  of  being  matched  by  any 
discrete  type  because  that  allows  the  reusability  to 
extend  to  a  universe  that  includes  things  other  than 
just  numbers.  The  universe  of  discrete  objects  could 
consist  of  the  alphabet  or  any  lists  of  enumeration 


literals  such  os  train  stations  or  other  things  you  may 
wont  to  Identify  os  belonging  to  a  set. 

This  problem  is  not  particularly  difficult  to  implement 
but  H  does  provide  an  opportunity  to  apply  the  Aria 
language  in  a  way  which  was  intended  by  its  auttrors. 


SUMMARY 

Even  without  formal  training  tire  experienced 
programmer  will  no  doubt  eventually  learn  to  write 
Ada  programs  that  will  work  but  they  will  probably  not 
achieve  tire  language  goals  and  w2l  assuredly  result 
in  Increased  development  costs.  Tire  major  abuses 
that  appear  will  be: 

1.  Lack  of  readability 

2.  Lack  of  reusability 

3.  Misuse  of  Ada  features 

4.  Failure  to  use  Ada  features  which 
contribute  to  tire  accomplishment  of  the 
lairguage  goals 

This  problem  set  was  designed  to  help  tire  student 
overcome  tfrese  difficulties.  Tire  use  of  a  uniform 
template  as  a  starting  point  for  tire  doss  frelps  to 
address  ttre  readability  and  reusability  issues.  Tire 
student  Is  started  in  ttre  right  direction.  The  selection 
of  tfrese  five  problems  highlights  many  of  tire 
Important  language  features  which  are  essential  to 
writing  good  Ada  code. 

Those  features  include: 

1 .  Input-Output  (Sequential  and  Text) 

2.  Packages 

3.  Records 

4.  Functions 

5.  Exceptions 

6.  Private  Typos 

7.  Attributes 

In  addition.  Implementation  dependencies  and  style 
issues  are  highlighted.  Furthermore,  the  use  of  Ada 
development  tools  is  required  as  part  of  the  problem 
solution.  This  kind  of  direction  enables  the  student  to 
produce  solutions  that  use  good  Ada  code.  Tire 
student  gains  an  appreciation  of  what  is  expected 
from  the  language.  When  good  coding  habits  are 
established  during  the  initial  learning  phase,  the 
results  will  be  a  continued  growth  in  ability  to  use 
rather  than  misuse  Ada.  Tire  DoD  goals  of  reduced 
costs  to  produce  code  that  is  readable,  maintainable, 
reliable,  and  reusable  will  be  achieved. 
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Ahatracr 

Teaching  Ada  la  considered  a  ehallen\lng  cask 
for  nose  educator*.  The  also  of  the  language,  the 
presence  of  nentradlcienal  structures  and  the  com¬ 
plexity  of  parallel  processing  are  sera  of  the 
reasons  for  this  challenge.  Ada  training  In  the 
industry  Involves  additional  constraints  and  brings 
new  challenges  to  the  instructor.  To  is  paper  pre¬ 
sents  the  experiences  of  one  Instructor  In 
teaching  Ada  to  Industry  professionals.  The  paper 
concludes  with  a  collection  of  guidelines  thac  have 
proven  effective  In  conducting  slallar  Intensive 
courses. 


Introduction 

Mien  teaching  In  acadeala,  the  Instructor  can 
usually  sake  valid  assusptlcns  about  the  skills  of 
the  students.  These  ossuoptlons  generally  provide 
guidelines  to  selecting  the  proper  level  of  In¬ 
struction  and  the  aaount  of  coverage;  however, 
these  assusptlons  can  not  be  applied  when  training 
Industry  personnel.  The  training  period  is 
usually  such  shorter  and  the  students  coae  iron 
diverse  backgrounds. 

The  students  who  attended  the  10-day  Ada 
course  are  eanagers,  software  engineers,  pro- 
graoaers  and  other  personnel.  Sone  have  Halted 
progranatng  skills  while  others  say  have 
experience  In  FORTRAK,  COBOL,  Asseably  or  a  olll- 
tary  language.  Unlike  acadeala,  only  a  few  of  the 
students  have  faalllarlty  with  Pascal.  Tills 
diversity  creates  a  new  difficulty  In  teaching  Ada 
In  sueh  a  short  period. 

Student  Coals 

Each  student  has  a  different  reason  and  goal 
for  attending  the  course.  Managers  are  Interested 
In  bccoalng  faalllar  with  basic  principles  ard 
features  of  Ada.  Software  engineers  nay  be 
Interested  In  learning  how  Ada  can  help  then  with 
design  issues  In  conplcx  projects.  Progranccrs 
slnply  want  to  learn  all  of  the  language  details 
since  they  will  be  coding  in  Ada  in  the  near  fu¬ 
ture.  As  difficult  as  it  nay  seen,  it  is  possible 
to  incorporate  a  careful  and  non-aggressive  ap¬ 
proach  in  presentations  that  can  satisfy  the 
expectations  of  all  attendees. 


Topla_and  Marhod*  of  Instruction 

The  students  were  usually  given  tlae  off  froa 
their  dally  responsibilities  to  attend  the  course 
on  a  full-tine  basis.  Availability  of  a  coaputer 
laboratory  Is  absolutely  vital  for  a  better  under¬ 
standing  of  the  language  and  hands-on  training. 
Lectures  that  exceed  SO  or  £0  ainutes  In  length  ate 
very  likely  to  becoae  tiring.  This  aay  cause 
individuals  to  lose  Interest  In  the  subject.  The 
dally  schedule  should  coablne  a  alxture  of  clasr- 
rooa  instruction  and  laboratory  practice  using  an 
alternating  forsac.  There  should  also  be  appro¬ 
priate  breaks  between  each  session.  Early  In  the 
course  only  one  lecture  hour  was  Included  in  the 
afternoon.  Later,  the  students  spent  all  of  the 
afternoon  hours  working  on  the  lab  asslgnsents.  On 
the  average,  the  students  spent  AO*  of  their  tloe 
In  the  classroom  and  601  In  the  computer  lab. 

All  lectures  were  video  taped  and  were  cade 
available  to  students  at  the  end  of  each  day. 

Courao  Outline 

Students  had  access  to  several  reference  books 
throughout  the  course.  A  copy  of  all  handouts  In  a 
textbook  foraat  was  nada  available  to  each  student. 
The  outline  chosen  to  cover  Ada  was  aa  follows: 

1.  Introduction 
-Brief  history 

-Ada  and  Software  Engineering 
-Structure  of  Ada  progrnns,  sicplo  types 

2.  Subprogram 

3.  Control  Structures 

-If  stocs.,  loops,  exceptions 

A.  Scalar  Data  Typos 

5.  Packages 

6.  Composite  Data  Typos,  Flics 

7.  Access  Types,  Private  Types 

8.  Ccnorlcs 

9.  Tasking 

All  staple  and  conposlte  types  were  covered  in 
detail.  Packages,  private  types,  and  control 
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structures  wore  given  extra  attention.  The  re¬ 
maining  topics  were  covered  on  an  introductory 
level  by  presenting  the  major  features  and 
structures  fron  each  group.  At  the  end  of  the 
course  the  students  were  given  a  list  of  the 
topics  which  were  not  covered.  The  seudents 
gained  enough  knowledge  and  training  from  the 
course  that  they  could  easily  learn  other  language 
features  individually.  Some  of  the  topics  that 
were  not  covered  include:  casks  with  family  of 
entries,  pragmas,  and  low-level  1/0. 

Assignments 

There  were  two  types  of  exercises:  review 
problem*  and  programing  assignaents.  The  review 
problem  were  a  collection  of  staple  questions 
that  were  given  to  the  class  every  day  during  the 
last  lecture  hour.  The  purpose  of  these  assign¬ 
aents  was  to  recall  the  topics  covered  during  the 
day  and  to  familiarise  the  student  with  the  syntax 
and  seaancics  of  the  language.  1c  also  helped  noi. 
programer  students  beeoae  acquainted  with  Ada 
code.  The  problem  solutions  were  aade  available 
during  the  aaae  hour. 

Each  programing  aasignaenc  was  composed  of 
two  or  three  problem  having  different  difficulty 
levels.  Each  student  was  asked  to  select  a  problem 
and  implement  it.  This  nechod  proved  beneficial 
since  students  did  not  share  comcn  programing 
skills  and  the  course  did  not  beeoae  coo  deaandlng 
for  those  who  were  not  going  to  code  in  Ada.  Stu¬ 
dents  felt  comfortable  with  the  language  as  they 
were  not  cocpccing  against  co-workers. 

Hie  following  is  a  brief  sumary  of  the  pro¬ 
graming  problem  that  were  aade  available. 

Assignnent-l 

A.  Write  a  progrna  to  conpucc  u  person's 
age. 

8.  Implement  and  test  the  conversion 
functions  Tnehoa^co^Cencinatera, 
Vnhrcn_to_Col8ius,  puarts_to_i.lcers. 

Asaip.nocnt-2 

A.  Using  the  given  algorithm,  write  the 
function  Squarejtoot  and  print  the 
table  of  square  roots  fur  nuabers  froa 
1.0  to  10.0  in  steps  of  0.5. 

B.  Write  n  progron  to  calculate  tbe  weekly 
ujges  of  an  employee. 

Asslgnpcnt-3 

A.  Using  the  square  root  function  froa 
asslgnacnt-2,  write  o  progrna  to  print 
the  wlndchlli  factor  table. 

B.  Convert  tbe  conversion  functions  of 
assignocnt-1  into  a  package. 

C.  Convert  the  payroll  progrna  of  assign¬ 
ment^  into  a  package. 


Assignment^ 

A.  Implement  the  package  ClaasJiaaterJPkg 
to  provide  resources  needed_to  grade  a 
class  of  students. 

B.  Implement  the  package  StackJ'kg  and 
provide  the  comen  stack  operations. 

Assipnaenc-S 

A.  Using  the  stack  package  froa  assignment 
-4  write  a  program  to  determine  if  a 
given  piece  of  text  contains  balanced 
parenthesis. 

B.  Using  the  stack  package  and  the  given 
algorithm,  write  a  program  to  convert 
an  infix  expression  into  the  postfix 
notation. 

Assignmenr-fi 

A.  Write  a  generic  procedure  called 
Array_Soarch  to  search  an  array  for  a 
glven“itea. 

B.  Modify  the  StackJ’kg  to  use  a  linked 
list  structure.  " 

C.  Convert  the  StaekJ’kg  into  a  generic 
package. 

Assignment-? 

A.  Write  independent  tasks  to  find  the  nax 
and  min  of  a  list  of  Items  stored  in  an 
array. 

B.  Write  a  program  to  implement  the  fol¬ 
lowing  tasks: 

InputJTask  :  read*  in  a  list  of 

words  from  a  data  file 
and  stores  them  in  a 
buffer  by  calling  the 
BufferJTnsk. 

BufferJTask  :  a  server  cask  with  en¬ 
tries  for  deposit  and 
removal  of  data  item. 

OutpucJTank  :  reooves  data  icons  froa 
the  buffer  task  and 
stores  then  in  a  data 
file. 

Student  Evaluations 

The  attendees  of  two  courses  were  surveyed  to 
evaluate  the  overall  quality  of  the  instruction. 
The  following  sunnary  is  the  evaluation  of  a 
group  composed  of  nanogers  (5Z),  software  engi¬ 
neers  (17Z),  programmers  (39Z),  and  other  person¬ 
nel  (39Z) . 

According  to  Che  survey,  15Z  of  the  students 
found  that  the  Ada  history  could  be  eliminated 
fron  the  course.  About  16Z  were  interested  in  in¬ 
cluding  Pragnas  in  the  course.  More  than  half  of 
the  students  Indicated  that  tasking  and  generics 
should  be  covered  in  Dorc  depth.  More  than  65Z  of 
the  attendees  believed  it  was  a  good  idea  to  use 
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the  standard  1/0  instantiations  after  studying 
generics  (the  instructor  used  pre-instantiations 
of  IntegerJUS  and  Float^IO  for  input  and  output). 
Half  of  the  students  believed  the  assignments  were 
fair  and  28X  found  chon  staple.  The  course  length 
was  Just  right  according  to  72T  and  finally,  ©ore 
than  9 bt  of  all  students  believed  that  the  lecture 
periods  were  sufficient. 

guana rv 

It  is  the  instructor's  experience  and  the 
students'  overall  response  that  Ada  can  be  taught 
effectively  to  Industry  professionals  in  short, 
Intensive  courses.  In  order  to  cover  cost  of  the 
language  features,  the  training  period  should  not 
be  less  than  10  days.  Other  factors  that  are 
found  to  be  beneficial  in  conducting  such  courses 
are  as  follows: 

1.  The  students  should  be  given  time  off  to  at¬ 
tend  the  course;  otherwise,  job  responsibili¬ 
ties  can  create  a  lack  of  else  and  interest  in 
Ada  which  defeats  the  training  purposes. 

2.  A  computer  facility  rust  be  accessible  to  pro¬ 
vide  hands-on  practice.  The  instructor  should 
be  available  in  the  lab  to  assist  the  students 
with  their  problem  and  to  provide  personal 
guidance  on  design  Issues. 

3.  Lectures  should  not  exceed  SO  minutes  and 
should  be  followed  by  lab  practices.  Total 
lecture  hours  during  the  day  should  not  exceed 
three.  Maximum  tine  for  the  afternoon  lecture 
should  be  one  hour.  To  reduce  the  intensity 
of  the  course,  short  breaks  between  sessions 
are  highly  recoaocndcd. 

4.  If  possible,  lectures  eight  be  video  taped  to 
provide  the  students  additional  reinforcement. 

5.  Students  do  not  usually  share  cocoon  skills; 
therefore,  each  assignment  should  provide  pro¬ 
blem  with  varying  levels  of  difficulty  to 
ecec  the  needs  of  every  individual. 

6.  Ac  the  end  of  the  course  the  students  should  be 
recognised  by  awarding  certificates  of  atten¬ 
dance. 
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Integrating  Ada  Training  with  Software  Development 

Pauline  Fortin  and  Freeman  L.  Moore 
Computer  Systems  Training 
Texas  Instruments  Incorporated 
Dallas  Texas  75265 


ABSTRACT 


Texas  Instruments  has  been  providing  training  to  its 
engineering  staff  since  1977,  with  a  curriculum  that  has 
evolved  with  time  and  experience.  The  introduction  of  Ada 
training  in  1933  and  more  recent  emphasis  on  requirements 
analysis,  has  provided  the  impetus  to  integrate  the 
curriculum  of  available  courses  into  a  coherent  software 
engineering  curriculum,  covering  the  full  DoD-STD-2l67A 
life  cycle.  The  Ada  programming  language  affects  several 
courses,  which  we  have  tied  together  using  common 
approaches,  and  common  exercises.  H'c  see  this  as  vital 
towards  our  efforts  of  maximising  the  training  resources 
available  to  software  engineers. 

INTRODUCTION 

The  Computer  Systems  Training  branch  within  Texas 
Instruments  has  been  providing  needed  training  forsoft  ware 
engineers  in  the  Defense  Systems  and  Electronics  Group 
(DSEG)  since  1977.  Ada  training  was  first  introduced  in 
1983  with  a  five  day  introductory  course  with  hands-on 
experience.  This  course  has  been  the  staple  of  tire  Ada 
training  curriculum  and  has  had  an  impact  on  the 
development  of  other  courses  in  the  software  engineering 
curriculum  offered  within  Texas  Instruments. 

The  introductory  course  has  been  supplemented  with  an 
advanced  topics  course,  manager's  overview,  turd  technical 
proposal  issues  workshop.  In  the  interest  of  maximizing  tire 
benefits  of  training,  a  comprehensive  review  of  the  computer 
systems  training  curriculum  was  undertaken  to  determine 
where  courses  overlapped  each  other  and  to  determine  how 
courses  could  betterrelate  to  one  smother. 

With  a  history  of  separate  courses  which  cither  present 
portions  of  the  Ada  programming  language,  or  provide 
overviews,  Texas  Instruments  has  chosen  to  look  at  the 
entire  set  of  courses  in  an  attempt  to  integrate  the  curriculum 
available  to  our  software  engineers.  The  analogy  to  a  salad 
bar  has  been  made  about  the  courses  that  were  available  in 
the  past  --  that  is,  the  prospective  attendee  can 
pick-and-choose  what  is  wanted,  without  any  guarantees  of 
getting  a  complete  and  balanced  selection.  This  has  been 
partially  resolved  by  the  introduction  of  training  plans  which 


provide  for  organized  paths  for  satisfying  training  needs. 
We  lave  learned  about  the  needs  of  the  engineering  staff 
during  die  development  of  courses,  and  we  are  expanding 
tltc  training  opportunities  to  cover  tlte  complete  life-cycle. 

m 

CURRICULUM 


Most  of  the  software  development  in  DSEG  supported 
embedded  microprocessor  systems  running  a  real-time 
environment.  As  a  general  rule,  the  M1L-STD-1750A 
processor  is  used  altltongh  other  microprocessors  are  being 
introduced.  Tlte  MIL-STD-1750A  is  a  16-bit  instruction  set 
architecture  developed  by  the  Air  Force.  Within  DSEG, 
there  are  many  diverse  projects  working  under  an 
everchanging  set  of  requirements,  developed  according  to 
military  standard  specifications  and  documentation 
requirements.  These  projects  may  involve  electro-optics, 
avionics,  missile  systems,  or  software  development 
applications.  The  primary  thrust  is  real-tinte  systems,  with 
an  increasing  emphasis  on  making  Ada  applications  work 
within  embedded  systems. 

Figure  1  represents  the  basic  training  model  for  DSEG 
software  engineers.  Some  of  the  courses  support  software 
development  skills  whereas  others  involve  software 
engineering  training  using  CASE  toolsets. 

The  Software  Engineering  Workshop  is  a  three-day  course 
to  assist  software,  electrical,  and  mechanical  engineers  who 
are  developing  software.  The  course  introduces  DSEG 
software  practices,  standards,  and  DoD-STD-2167A  [2]  life 
cycle  requirements.  Participants  work  in  teams  to  analyze 
actual  project  documentation,  write  portions  of  a 
requirement  specification,  and  participate  in  a  Software 
Specification  Review. 

A  Software  Quality  Assurance  (SQA)  Orientation  Class  is 
available  for  software  quality  assurance  engineers  after 
attending  the  Software  Engineering  Workshop.  This  is  a 
three-day  course  which  introduces  the  attendee  to  SQA 
practices  in  the  product  lifecycle.  Participants  work  in  teams 
to  define  evaluation  criteria,  audit  test  results,  trace  test 
requirements  to  requirements  specifications,  and  evaluate 
approved  DSEG  project  documentation. 
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Figure  1 


Real-Time  principles  arc  fundamental  to  software 
development  performed  within  DSEG.  Computer  Systems 
Training  provides  an  "Introduction  to  Real-Time  Systems" 
course  to  supply  the  necessary  background  to  those 
engineers  who  need  it.  Other  course*  deal  with  the 
architecture  issues  of  a  M1L-STD-1750A  processor,  as  well 
as  how  to  microprogram  array  processors  tliat  are  used  by 
some  projects. 

"In  the  ncartemi,  says  Barry  Boehm...  most  organizations 
could  double  software  productivity  using  nothing  more  than 
the  best  software  practices  and  tecluiologies  already 
available."  [3]  Our  DSEG  CASE  Steering  Committee 
recognizes  this  importance  on  standardizing  an  approach  to 
software  development.  Our  approach  is  based  upon  work 
done  by  Paul  Ward  and  documented  in  his  books  [4].  We 
now  have  in  place  a  real-time  structured  analysis  course, 


followed  by  a  structured  design  course.  The  design  course 
extends  the  analysis  by  developing  the  application  model 
from  the  analysis  course  into  a  top  level  software  design 
model. 

CASE  toolsets  are  gaining  acceptance  and  credibility  in  the 
software  design  community.  Software  engineers  are  now 
using  software  that  costs  more  than  the  hardware  it  nins  on. 
CASE  toolsets  help  automate  some  of  the  work  involved  in 
documenting  the  products  of  structured  analysis  ;uid  design. 
The  toolsets  can  even  provide  some  help  in  code  generation 
mid  producing  military  standard  documentation.  The 
capabilities  of  Excclenitor/RTS  are  taught  in  a  hands-on 
course. 

The  Ada  component  of  the  curriculum  is  perhaps  the  most 
stable,  yet  the  most  dynamic  portion.  Grady  Booch's  book 


7th  Annual  National  Conference  on  Ada  Technology  1989  317 


(5)  provides  the  basil  for  our  introductory  course,  which  lias 
been  available  for  five  years.  Hie  course  has  changed 
support  environments,  from  NYU  Ada/ED  to  Data  General, 
to  Dec-Ada,  and  now,  workstations.  Tlic  cotirses  liavc 
stressed  proper  software  development  (not  simply  syntax). 
With  the  Introductionof  tbcTmtan  Ada/1 750A  compiler,  we 
arc  in  the  process  of  developing  additional  training  aids  to 
satisfy  demand  for  processor  specific  training. 

Tl»e  Software  Engineering  Project  Management  course 
helps  software  managers  and  lead  engineers  to  plan,  budget, 
and  control  software  projects.  The  course  uses  case  studies 
ami  handouts  that  deal  with  typical  software  life-cycle 
deliverables  in  conformance  with  DSEG  software 
methodology  and  the  DoD  acquisition eycic.  We  revised  this 
course  in  early  1988  to  acconunodate  additional  data  about 
managing  Ada  projects. 

CURRICULUM  INTEGRATION 


To  remove  the  "salad-bar"  image  of  the  software 
engineering  curriculum,  it  lias  been  necessary  to  review  tlic 
content  of  tlic  various  courses.  By  understanding  why  a 
course  is  needed,  we  are  better  able  to  define  bow  die  courses 
can  interface  with  one  another.  For  example,  several  of  the 
later  courses  assume  knowledge  of  DoD-STD-2l67A  for 
documentation  purposes.  Beyond  liaving  prerequisites  for 
courses,  we  liavc  chosen  to  integrate  the  content  of  certain 
courses. 

For  example,  the  SW  Engineering  Workshop  introduces  the 
DoD  lifccyclcand  documentation  requirements  by  means  of 
a  case  study.  Real-Time  stmetured  analysis  topics  are 
introduced  to  lead  into  die  Real-Time  Structured  Analysis 
course.  Die  case  study  used  in  the  Real-Time  Stmetured 
Analysis,  Structured  Design,  and  Excelcrator/RTS  courses 
is  tlic  same,  the  low  level  control  of  a  plotter.  The 
implementation  phase  of  the  plotter  was  recently  introduced 
into  the  introductory  Ada  course,  adding  yet  another 
conunon  thread  between  the  courses. 

Tlic  Structured  Design  course  introduces  people  to  the 
concept  and  notation  of  program  design  languages  (PDL), 
which  is  continued  into  practice  in  die  Introductory  Ada 
course.  With  the  availability  of  better  workstation 
compilers,  we  have  chosen  to  teach  four  out  cf  die  five  days 
using  a  worksta'ion  environment.  The  last  day  of  the  course 
will  deal  with  intftJ«.ing  with  a  VAX  environment  and  its 
set  of  tools  for  Ada  development.  This  represents  a  recent 
change  from  when  the  course  was  entirely  VAX  oriented. 
Tlic  workstation  environment  we  have  selected,  IntegrAda 
[6],  provides  an  interface  for  using  PDL  notations  which  is 
consistent  with  VAX  based  tools. 

As  noted  above,  the  use  of  one  or  more  case  studies  has 
allowed  use  to  reinforce  the  connections  between  the  various 


classes,  and  provides  aconsistcnt  application  from  which  the 
student  can  icam.  Starting  from  the  analysis  phase  through 
die  implementation  plia.se,  students  arc  exposed  to  all  facets 
of  a  problem  with  which  tliey  lave  become  quite  familiar. 
Some  of  die  common  diread*  are  identified  in  the  appendix. 

INTEGRATING  ADA  INTO  THE 
CURRICULUM 

As  previously  mentioned,  Ada  has  been  n  part  of  die 
Computer  Systems  Training  curriculum  for  several  years. 
With  a  review  ofrbc  entire  software  engineering  curriculum 
needed,  a  review  of  die  Ada  curriculum  is  also  in  order.  Tills 
was  facilitated  in  part,  by  the  introduction  of  two  additional 
instructors,  who  offered  their  fresh  perspectives  on  the 
content  and  role  of  die  Ada  courses. 

In  1 988,  we  added  a  real-time  structured  design  course  to  our 
curriculum,  introducing  this  course  has  required  us  to  review 
the  approach  that  Booch  takes  to  object-oriented  design  in 
his  book.  It  was  necessary  for  us  to  refine  minor  portions  of 
both  courses  to  make  die  content  flow  consistently  from  one 
course  to  die  otlicr.  Our  approach  is  to  continue  the  use  of  tlic 
transformation  schema  and  structure  diarts  from  die 
Analysis/design  course,  refining  the  infomation  content 
into  "booch-grams"  used  in  tlic  Ada  course.  We  lave 
resisted  introducing  new  graphical  notations  due  to  die 
nature  of  the  CASE  tools  we  have  available  (7). 

Tlic  concept  of  a  program  design  language  (PDL)  is  used  in 
the  stmetured  design  course  as  a  means  of  writing  process 
specifications.  With  the  use  of  IntegrAda  in  die  Introductory 
Ada  course,  we  are  able  to  continue  the  use  of  PDL 
annotations  easily  as  part  of  developing  solutions  to  exercise 
problems.  The  Advanced  Ada  course  continues  this 
emphasis  on  design  notation  by  utilizing  the  AdaDL  toolset 
to  produce  a  software  design  document.  AdaDL  is  an  Ada 
Program  Design  Language  supported  by  VAX  hosted  tools 
18). 

The  importance  of  DSEG  Prognuiuning  Standards  is 
identified  in  the  Software  Engineering  Workshop,  Software 
Quality  Assurance  workshop,  and  reinforced  in  the  Ada 
classes  with  attention  drawn  to  die  content  of  the  standards. 
Discussion  is  also  niised  about  the  motivation  of  some  of  the 
standards,  such  sis  restricting  the  with  and  r/borr  statements. 

We  find  it  necessary  to  integrate  the  role  of  the  lifecycle  with 
software  development  as  practiced  in  the  Ada  classes.  This  is 
evident  in  the  structure  of  the  exercises  developed,  starting 
with  analysis,  top-level  design,  detailed  design,  and  then 
implementation.  One  of  the  programming  exercises  is  a 
modification  of  existing  software,  allowing  them  the 
opportunity  to  work  at  the  maintenance  phase  as  well. 
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Our  introductory  Ada  eountc  covers  the  entire  Ada 
programming  language  in  five  elass  days.  The  programming 
labs  include  time  where  students  have  an  opportunity  to 
exercise  most  of  the  language  features.  We  have  taken  lire 
approach  of  letting  lire  Advanced  Aria  eoursc  deal  with 
efficiency  issues.  We  find  this  approach  useful  since 
students  will  have  learned  the  complete  language  in  the 
Introductory  Ada  course,  ami  now*  are  refining  their  design 
and  implementation  skills  in  the  Advanced  Adacoursc.  This 
is  earned  a  step  funltcr  in  our  Ada/ 1750 A  training  by 
addressing  languagc/proccssor  specific  details  in  depth  in 
this  material. 

Oik  of  the  goals  of  our  Ada  training  is  to  continue  the 
involvement  of  the  instructors  beyond  iIk  classroom 
environment  Into  the  project  world.  This  benefits  both 
instructor  ami  project.  The  instructor  Is  kept  up  to  date  with 
how  material  is  being  applied  on  the  various  projects.  The 
project  benefits  by  having  an  outside  Ada  expert  available 
for  candid  review  of  software  and  documentation. 

ASSESSMENT  OF  TRAINING 
EFFECTIVENESS 

Most  courses  have  exercise  components  to  reinforce 
concepts  discussed  in  lecture.  To  encourage  iIk  completion 
of  exercises,  completion  certificates  are  provided  to  those 
tiiat  successfully  finish  (Ik  work.  The  class  schedule 
provides  time  to  finish  work  during  class,  although  a  few 
people  may  require  cxtratinKintheAdaeoursestaeomplctc 
the  work'This  has  been  accomplished  in  the  past  by  making 
iIk  necessary  computer  accounts  available  for  oik 
additional  week  after  the  class. 

'IIk  effectiveness  of  our  training  activities  is  measured  by 
several  means.  First  is  the  informal  observation  by  (Ik 
instructor  of  the  class.  The  questions  raised  by  the  people 
often  provide  the  necessary  clues  as  to  the  quality  of  the 
training,  and  the  on-tlte-spot  customization  often  needed 
when  dealing  with  classes  with  diverse  backgrounds. 
Projects  have  requested  special  offerings  of  the  Ada  training 
courses  which  has  required  additional  preparation  by  the 
instructors  have  tlK  training  reflect  the  needs  of  the  project 
environment. 

Toward  the  end  of  each  class  delivery,  a  standard  Participant 
Evaluation  Form  is  passed  out  to  the  attendees  to  complete  in 
a  multiple-choice  fashion.  Written  comments  are 
encouraged,  but  often  are  not  collected  in  an  organized 
fashion.  The  Participant  Evaluation  Form  is  machine 
scored,  with  results  being  merged  into  a  department 
database.  By  looking  at  the  results  over  a  period  of  time, 
trends  can  be  detected  and  acted  upon  if  necessary. 


We  Iwvc  started  to  introduce  (Ik  concept  of  pre  ami 
post-testing  tn  sotik  courses.  We  sec  this  ax  (Ik  opportunity 
to  document  that  a  course  is  achieving  a  training  goal  in  a 
measurable  sense.  This  work  was  recently  begun  and  will 
continue  to  expand. 

LEARNING  FROM  OUR  MISTAKES 


Our  curriculum  lias  cluuigcd  over  time.  For  inxtarKc,  iIk 
courses  dealing  with  Pascal  that  were  taught  just  three  years 
ago,  are  no  longer  taught  due  to  our  emphasis  on  a  single 
language,  Ada.  It  took  us  too  long  to  develop  a  edwrent 
picture  of  software  development,  ami  Integrate  it  with  the 
woik  environments,  starting  with  PC-based  work  tlirough 
VAX-based  dcvcIoptiKtu. 

WJ»cn  «Ik  Introductory  Ada  course  was  first  Introduced,  it 
was  offered  as  a  five  day  course,  presented  in  one  week.  We 
have  since  modified  this  deliver)'  schedule  to  have  the  same 
five  days  spread  out  over  a  two  week  period,  meeting  every 
otlwr  day.  We  have  foutid  the  extra  day  between  class  days 
reduces  the  Impression  that  a  great  deal  of  Information  was 
being  presented.  11k  course  content  is  the  sanK,  just 
delivered  over  two  weeks  time  instead  of  one. 

We  have  cliangcd  our  examples  ami  exercises  to  reflect 
project  iKeds.  Ourjtudcnts  arc  here  to  learn  how  to  apply  the 
language  back  on  the  job.  Having  relevant  examples  is  one 
way  of  having  the  course  reflect  the  job  requirements. 
Another  way  is  to  make  sure  the  software  training 
environment  is  the  sanK  as  the  work  environriKnt.  We  find 
projects  are  switching  to  workstations  for  software 
development.  This  has  been  reflected  in  our  Introductory 
Aria  course  switching  from  the  VAX  environment  to  a 
workstation  for  training  purposes.  We  have  kept  in  an 
exercise  dealing  with  the  VAX  environment  to  satisfy  those 
students  who  have  the  requirement  of  doing  software 
development  on  a  VAX. 

A  group  level  decision  about  the  role  of  training  has  made  a 
substantial  impact  on  the  direction  of  our  work.  Witliout  this 
direction,  training  was  primarily  used  to  meet  an  imnKdiate 
need.  With  training  plans  in  place,  we  are  seeing  a  more 
organized  approach  to  raising  the  skill  level  of  a  larger  group 
of  soft  ware  engineers,  instead  of  isolated  groups  as  before. 

FUTURE  WORK 


To  complete  the  training  from  a  life-cycle  perspective,  we 
need  to  fill  a  gap  in  iniegralion/testing.  We  shall  be  attacking 
this  problem  in  1989.  We  are  continuing  our  development  of 
training  for  Ada  as  implementations  become  available  on 
various  processors,  including  the  TMS320C30  signal 
processor. 
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Our  goal  has  been  to  Integrate  Ada  training  with  oursoftwarc 
dcvelopn*cnt  curriculum.  We  believe  that  we  have 
essentially  met  this  challenge.  We  foutxl  tlwt  several 
courses  were  affected  in  the  process.  Integrating  the  courses 
meant  more  than  adding  prerequisites.  TJ>c  greatest 
challenge  is  not  in  providing  the  best  e nurse  on  Aria  training, 
but  rather  making  sure  that  Ada  is  properly  used  as  (he 
vehicle  towards  building  bcttcrcnginecrcd  systems. 
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APPENDIX:  Common  Threads 

Between  Courses 

Software  Engineering  Workshop: 

Introduces  DoD-STD-2167A,  project  background,  need  for 
standardized  software  development. 

Real-TimeStmctured  Analysis: 

Relates  methodology  to  2 167 A  environment,  defines  steps 
to  follow,  introduces  case  study ,  and  exercises. 

Real-Time  Structured  Design: 

Continues  structured  analysis  methodology  using  same  case 


study  and  exercise.  Introduces  PDL  notation  to  describe 
processingcompoocnts. 

I-  \ccLcrator/RTS  Fundamentals: 

Implements  notation  of  stmetured  analysis/dcsign  on 
Excclcrator/RTS  toolset  using  a  comtnon  example  from  the 
SA/SD  course,  a  Plotter. 

Fimdamcntalsof  Ada  Design  and  Programming : 
Objeet-orientation  is  followed  from  the  structured  design 
eotirsc,  with  implci:)cnta(ion  of  the  Plotter  which  was  used  in 
the  mialysis,  design,  and  Execlcrator/RTS  courses.  PDL 
notation  is  used,  following  on  the  notation  introduced  in  the 
design  course. 

Ad  vancedTopics  in  Atla: 

Relates  topics  back  to  system  analysis  and  design  concerns, 
reinforcing  object  orientation.  Provides  greater  detail  on  the 
use  and  benefits  of  PDLas  a  means  to  describe  processes. 
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SOFTWARE  ENGINEERING  REQUIREMENTS  ANALYSIS  (SERA) 


Jag  Sod hi 


TELOS  Federal  Systems 
Lawton,  Oklahoma 


ABSlKACr 

Undemanding  and  analyzing  a  customer's  requirement*  for  a 
system’s  software  engineering  is  ;he  primary  focus  of  this 
paper.  This  paper  evaluates  the  teaching  of  the  Software 
Engineering  Requirements  Analysis  (SURA)  Course  for 
understanding  and  analyzing  the  customer's  requirements  of 
real-time,  embedded  systems.  The  systems  software 
engineering  arc  being  developed  in  Ada  for  US  Army 
Communieaiions-Elceironies  Command  (CECOM),  Fire 
Suppon  Systems,  and  Life  Cycle  Software  Engineering 
Centers  (LCSEC). 


iNTROPUCTiON 

A  system  needs  analysis  fust  Including  proto-type  modeling 
before  starting  the  system's  design  *  Preliminary  design  and 
Detailed  design.  The  SERA  course  uses  structured  techniques 
to  graphically  analyze  customer  requirement*.  The  techniques 
separate  the  requirements  into  manageable  logical  independent 
functions.  The  relationship  of  functions  and  objects  arc  then 
established  for  use  later  on  by  the  Object  Oriented  Design 
Method  (OODM)  and  Ada  advanced  features.  The  course 
covers  software  engineering  goals  and  principles.  The  course 
discusses  various  phases  of  tire  software  engineering  life  cycle 
development  phases  in  accordance  with  DOD-STD-2I67A  as 
illustrated  in  Figure  I. 

PARADIGMS  OFSERA 

SERA  has  gone  through  many  revisions  to  include  appropriate 
work-related  examples,  exercises,  and  case  studies.  A  generic 
real-time  example  as  shown  in  Figure  2  is  discussed  in  detail 
along  wills  many  exercises  and  case  studies.  Upon  completion 
of  the  course,  the  students  understand  the  various  phases  of 
software  engineering,  the  importance  of  system  modeling, 
(modeling  assists  in  importing  pre-tested  reusable  Ada 
packages  from  other  related  systems),  structured  technique  to 
analyze  requirements,  and  possess  at  least  one  view  of  the 
"blue  print". 

The  students  gain  practical  experience  in  performing  structured 
walk-throughs.  Exercises  are  included  to  give  the  student 
practice  in  analyzing  solutions  with  the  help  of  tools.  Tests 
and  quizzes  are  used  to  measure  the  students'  progress  and 
achievement. 

This  paper  also  discusses  how  SERA  can  be  automated  with 
the  help  of  Computer  Aided  Software  Engineering  (CASE) 
tools.  This  is  helpful  in  creating  quality  and  reducing  costs  of 
the  system  software  engineering  products.  Thus  the  systems 
produced  are  more  reliable  and  well  documented. 


oiARACnmyncs 

SERA  course  was  designed  on  the  basis  of  the  structured 
approach  to  understand  customer  requirements  ami  translate 
correctly  these  rcquircnrents  to  develop  software  efficiently 
and  cost  effectively  to  the  customer’s  satisfaction.  Software 
engineering  is  to  be  maintained  for  a  life  cycle  with  frequent 
ehangc*  implemented  from  the  users. 

The  first  SERA  course  was  experimented  with  by  Selecting  a 
few  professionals  to  walk-through  the  material.  The  lessons 
learned  were  included  in  future  revisions. 

The  eoursc  was  revised  to  suite  the  need  of  TELOS.  This  w  as 
used  for  the  in-house  education  and  training  of  professionals 
rather  than  only  an  educational  course.  The  expectation  was 
that  students  leant  from  hands-on  training  which  benefits  their 
work.  Tills  concept  is  different  than  the  commercial  courses 
available  in  the  market  where  the  students  are  provided  only 
exposure  to  the  subject  in  five  days. 

The  course  was  originally  prepared  to  be  offered  for  five  full 
days  duration.  Many  professionals  had  lime  constraints  to 
finish  their  assigned  tasks.  Then  classes  were  offered  ten  half 
days  with  a  lecture  in  the  morning  and  workshop  in  the 
afternoon  so  the  student  can  take  the  assignment  back  to  the 
offiec  to  complete.  I  experimented  with  all  of  these 
alternatives  as  suggested  by  the  students.  All  of  these 
suggestions  had  some  good  points.  Finally,  1  accepted  the 
majority  consensus  to  teach  the  course  for  three  full  days  with 
the  eonunitment  that  the  students  will  accept  and  complete  the 
workshop  as  homework.  This  technique  is  working  very 
well.  The  company  is  saving  time  and  money.  Each  student 
willingly  accepts  homework  and  spends  their  extra  time  to 
complete  it  on  time.  Some  of  SERA  teaching  characteristics 
are: 

•  Functionality 

•  Follows  set  standards 

•  Structured  approach 

•  Accuracy 

•  Consistency 

•  Modifiability 

•  Produce  quality  results 

•  Easy  to  understand  and  follow 
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Figure  2:  A  Real*Timc  Syitem  Context  Diagram 
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METRICS  AND  INDICATORS 

Metrics  arc  used  as  a  means  far  quamitivcly  assessing  the 
characteristics  of  teaching  SURA.  The  metrics  arc  indicators 
that  objectively  assess  the  quality  ©f  teaching  and  determine 
how  much  knowledge  the  students  lave  absorbed.  These 
indicators  aid  in  obtaining  valuable  feedback  from  the 
students.  The  student  evaluation  is  carefully  designed  la 
receive  the  correct  assessment  of  the  eoursc  as  shown  in 
brgure  3.  Seme  of  the  metrics  and  indicators  introduced  are: 

•  Tests 

•  Quizzes 

•  Mini  exercise* 

•  Students  nuke  their  own  work  related  ease  study  for 
tire  final  examination 

«  Walk-throughs 

•  Open  discussions 


STUDKNTHVAl.VATIOS.SIlIvKr 

COURSE  TKt.OS  Software  KnriwwJng 
Requirement*  Amljm  (SKRa) 
tltj:  JagSoitM) 

IJATfc 

NAMK:  UHt'r/SKCriOS:  . 

You  cun  makt  *  perMmxl  contribution  la  tbh  cITort 
by  nntwcrlng  the  following quotient: 

1.  What  did  )ou  like  mint  about  the  Course? 

2.  What  did  jou  like  tea*!  about  the  countc? 

J,  What  would  )ou  like  la  tec  deleted  tram  Iht* 
course? 

4.  What  would  jou  like  to  See  added  to  the  Course? 

5.  Are  )ou  willing  to  adopt  these  tool*  in 
jour  work? 

6.  If  no  to  *5,  ptease  glse  reasoning  why  Hof* 

7.  Any  additional  comments? 


Figure  3:  Student  Evaluation  Sheet 


The  parameters  are  characterized  among  the  professionals  for 
the  knowledge  gained  from  the  SERA  course.  They  have 
many  years  of  hard  experience  of  trying  to  mutually 
understand  the  customer's  requirements  for  developing 
software.  After  course  completion  they  appreciate  SERA’s 
usefulness  in  making  their  jobs"  performance  easier.  Teaching 
SERA  is  not  only  to  share  the  knowledge  but  to  infuse  into  the 


professionals  this  knowledge  so  that  they  can  utilize  these 
tools  on  the  job.  Tire  parameters  summarized  are: 

•  Professional  satisfaction 

•  Management  Return  of  Value  (ROV| 

•  High  morale  among  the  professional* 

•  Positive  feedback  from  the  students 

•  Increase  of  quality  products  on  the  Job 

•  lluild  team  spirit  in  the  company 

•  I mprovement  of  the  individual’s  job 

•  Effective  use  of  time  and  resources 

•  Increase  cooperation 

EVALUATION 

SERA  has  been  successfully  taught  to  over  one  hundred  fifty 
professionals  at  TELOS  for  the  last  two  years.  Each  one  of 
these  professionals  has  evaluated  the  eourxc  very  high.  The 
evaluations  have  many  positive  suggestions  which  have 
assisted  in  course  revisions  for  naking  it  more  presentable  and 
acceptable  by  professionals. 

The  concept  of  student  participation  was  stressed  throughout 
the  eoursc.  The  class  was  limited  to  six  students  for 
effectiveness.  This  scheme  leads  to  a  more  personal  touch 
between  the  students  and  the  teacher.  The  class  w-as  further 
divided  into  two  teams  to  introduce  the  team  concept,  each 
member  first  tried  the  case  study  himself  before  having  the 
walk-through  with  other  members  of  the  team.  Each  team 
selected  their  leader  for  a  ease  study  to  present  the  solution  on 
the  board.  The  other  members  of  the  team  walkcd-through  the 
solution.  The  team  members  assisted  and  supported  their 
presenter.  This  not  only  created  healthy  competition  but  also 
aided  tlw  students  to  leam  faster  in  a  sliortcr  time. 

All  available  tools  of  educating  and  training  arc  used  in  the 
classroom.  These  tools  are  the  vu-graph  (overhead  projector), 
board,  and  hands-on  computer  training.  1  have  always 
believed  in  teaching  a  little,  then  put  that  teaching  into  practice 
by  showing  an  example,  and  finally  providing  at;  exercise  to 
cement  the  training. 

At  the  beginning  of  class,  1  introduce  myself  and  request  each 
student  to  provide  a  brief  job  introduction.  This  also  helps  me 
adjust  the  teaching  for  that  set  of  professionals.  I  explain  the 
goals  and  objectives  of  the  SERA  eoursc.  a  brief  history  of 
how  this  in-house  education  and  training  initiated  and  what  I 
am  expecting  from  my  students.  The  criteria  of  their 
performance  in  the  class  will  be  evaluated  as  follows: 

•  Positive  attitude 

•  Work  as  a  team  member 

•  Constructive  comments 

•  Raise  constructive  positive  questions 

•  Active  participation 

•  Help  other  members  of  the  team 
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•  Cottvnunicatc  for  productivity 

•  Finish  hotncwork 

•  Prompmcss/punetuality  In  attending  the  elass  and 
eoroing  back  front  lunch  ami  breaks 

flic  students  evaluate  the  Silk  A  eoursc;  how  the  Instructor 
presented  the  eoursc.  Is  the  instructor  knowledgeable  enough 
to  answer  all  their  questions?  is  the  eoursc  useful  to  tneet  their 
job  needs?  Arc  the  examples,  exercises,  and  ease  studies 
related  to  the  Job?  Arc  they  willing  to  support  the  program? 
Do  they  want  any  change  in  the  materia!  or  the  program?  The 
evaluation  of  the  students  arc  statistically  compiled  and 
analyzed  as  follows: 

•  Tcaehcr 

•  Open  end  presentation 

«  Gets  everyone  to  participate  and  contribute 
.  Knows  the  subject 

•  Excellent  presentation 

-  Great  enthusiasm  to  ntotivate  students  to  learn  the 
subject 

•  Adjust  with  the  elass 

■  Well  prepared 

•  Right  logical  approach 

•  Positive  attitude 

•  Quality  Instructions 

•  Material 

•  Excellent  material 

•  Logical  format 

•  Structured 

-  Well  organized 

•  Quality 

-  Practical  case  studies 

-  Gear  explanations 

•  General  Comments 

•  Excellent  course 

•  Good  atmosphere 

•  Doing  exercises  instead  of  only  lecture 

•  All  members  of  the  class  learned  SERA 

-  Relaxed  atmosphere 

-  Smooth  continuity 

•  Teacher  presentation  and  material  tie  together 

•  Group  discussion 

■  Student  interaction 

•  Motivated  to  leant  by  doing  exercises  and  case 
studies 

•  Real  education  and  learning 

LESSONSJ.EARNED 

1  found  that  there  arc  four  basic  different  types  of  students. 

•  Innovative 

•  Analytical 

•  Inquisitive 

•  Practical 


The  innovative  students  arc  concerned  with  gaining  personal 
knowledge  through  discussions  and  interaction,  ana  asking 
question*  to  leant  "WHY*.  The  analytical  students  seek  the 
facts  about  an  issue  by  analyzing  ideas  or  knowing  and 
learning  by  asking  ’WHAT*.  The  inquisitive  students 
independently  carry  on  the  ease  studies  themselves  through  to 
completion.  They  learn  by  trial  and  error  and  self  discovery. 
They  gain  knowledge  hv  asking  "IP  I  DO  THIS,  WHAT 
WILL  HE  THE  PINA!.  RESULT*.  The  practical  students 
need  to  know  how  things  work  and  learn  through  hamls-on 
experiences.  They  believe  in  the  practical  application  of  Ideas, 
and  learn  by  asking  "HOW  DOES  IT  WORK*.  It  has  been  a 
challenge  for  me  to  satisfy  all  these  types  of  professionals. 

I  have  found  that  students  like  the  approach  of  developing  their 
own  work  related  ease  study.  They  select  a  requirement  and 
try  to  write  an  understandable  ease  study.  Often  one  hears  in 
the  computer  Industry  that  the  customer's  requirements  ate  not 
understandable  specially  when  the  project  Is  falling  or 
schedules  arc  slipping.  I  encourage  students  to  create  their 
own  meaningful,  understandable  requirement.  This  approach 
assists  students  to  understand  their  own  requirements  and 
produce  solutions  as  they  progress  and  learn  in  the  elass.  On 
tltc  final  day  of  elass  the  students  arc  given  a  chance  to  present 
anti  walk-through  the  solution  with  other  members  of  the 
class. 

I  experienced  that  the  selection  of  students  to  form  a  class  Is 
important.  These  students  arc  selected  front  different  sections 
so  that  they  can  leant  from  each  other's  experiences.  Then  the 
elass  is  divided  into  tw6  teams  of  three.  The  teams  arc  divided 
in  such  a  way  that  not  all  members  of  the  team  belong  to  the 
same  sceiior/dcpanmcm.  litis  scheme  provides  a  variety  of 
student  experiences  to  be  shared  with  each  other.  This  also 
creates  a  good  atmosphere  and  is  a  very  effective  learning 
result  as  evidenced  by  student  evaluations. 

I  teamed  that  the  students  prefer  to  have  an  Individual  work 
station,  lids  plan  assists  in  using  hands-on  training  on 
automated  tool  kits  in  the  workshop  more  effectively.  The 
work  station  should  have  a  good  Ada  compiler,  Debugger, 
Configuration  Management,  Editor,  and  Backup  facilities. 
There  arc  many  Computer  Aided  Software  Engineering 
(CASE)  tools  available  In  the  market  which  are  suitable  to 
one's  requirements.  I  use  Yotirdon  automated  tool  kit  for  my 
elasscs. 

CQSCmSIQM 

The  teaching  of  SERA  follows  easy  methods  to  help  computer 
professionals  to  understand  customer  requirements,  "he 
requirements  arc  translated  into  graphic  models  to  convince  the 
customer  easily  that  their  requirements  arc  understood  and  dr- 
software  will  be  developed  in  accordance  with  DOD-STD- 
2167A  in  Ada.  The  teaching  lays  out,  in  clear  detail,  exactly 
how  the  customer  requirements  should  be  mutually 
understood.  By  understanding  the  requirements  professionals 
take  a  smooth  journey  through  the  software  development 
phases.  This  approach  saves  time  and  money.  And  most 
important  of  all,  as  the  journey  progresses,  professionals  and 
the  customer  feel  more  and  more  comfortable  and  gain 
confidence  in  implementing  the  software  engineering. 

1  acknowledge  tint  the  evaluation  of  all  my  students,  who  have 
attended  SERA  course,  has  assisted  me  in  building  a  course 
worthy  of  presentation.  I  treat  every  class  as  a  project  to  be 
completed  in  time  and  successfully. 
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Abstract 

A  set  of  Ada  abstract  data  types  (ADTs)  is  the 
underlying  substrate  that  defines  a  common,  Ada- 
oriented  interface  to  diverse  host  environments,  The 
Ada  ADTs,  in  conjuction  with  the  use  of  Ada  as  a 
command  language,  serve  as  a  unifying  concept  in 
the  description  of  a  portable  Ada  command  envi¬ 
ronment.  The  benefits  provided  by  ADTs  and  Ada 
in  a  software  engineering  environment  are  extended 
into  the  command  language  arena.  The  Ada  Com¬ 
mand  Environment  (ACE)’  combines  the  power  of 
Ada  as  a  command  language  with  the  description  of 
the  host  environment  through  ADTs.  ACE  presents 
to  the  user  a  consistent  Ada-oriented,  development 
environment  that  supports  a  uniform  interface  across 
a  heterogenous  set  of  development  architectures. 

1  Introduction 

There  are  many  Ada  development  environments  available 
today  that  function  on  a  variety  of  platforms.  These  plat¬ 
forms  consist  of  both  hardware  and  the  necessary  support 
software.  Each  Aria  development  environment  provides  an 
interface  through  which  its  Ada  tools  arc  invoked  and  con¬ 
trolled.  Each  hardware  and  software  platform  provides  at 
least  one  command  interpreter  through  which  the  many  fa¬ 
cilities  provided  in  the  host  environment  are  accessed  and 
acquired.  Associated  with  a  command  interpreter  is  the 
command  language  which  defines  the  names,  syntax,  and 
interface  semantics  of  the  available  commands.  This  com¬ 
bination  of  Ada  environments  and  host  operating  environ¬ 
ments  presents  a  diverse,  formidable  set  of  paradigms.  The 
developer  must  be  familiar  with  the  conventions  of  both 
the  host  environment  and  the  particular  Ada  environment. 
The  differences  between  these  environments  makes  it  diffi¬ 
cult  for  an  Ada  developer  to  easily  move  between  different 
host  environments. 

Ada  compilation  environment  builders  have  taken  differ¬ 
ent  approaches  in  designing  the  interface  to  their  Ada  tool 

'The  work  described  herein  was  performed  under  Office  of  Naval 
llesearch  contract  number  N00OM-87-C-0743, 


suites.  Some  environments  have  adopted  the  style  and 
syntax  of  the  underlying  command  language. [6]  This  ap¬ 
proach  blends  their  tool  suite  with  one  of  the  command 
languages  supported  on  the  host  machine.  The  interface 
to  this  compilation  environment  may  then  change  when  the 
identical  Ada  environment  is  available  on  a  different  hard¬ 
ware/software  platform.  Other  environments  have  adopted 
the  style  and  syntax  of  the  Ada  programming  language. [5] 
This  approach  incorporates  some  of  the  features  of  Ada 
(e.g.  procedure  call)  into  the  command  language.  With 
this  approach,  a  more  uniform  Ada  compilation  environ¬ 
ment  may  be  available  on  a  diverse  set  of  platforms. 

However,  interfacing  with  the  Ada  compilation  environ¬ 
ment  is  only  one  of  the  typical  tasks  performed  by  an  Ada 
developer.  Some  of  the  other  tasks  performed  include  the 
management  of  file  objects  (e.g.  create  a  file,  list  a  di¬ 
rectory,  type  the  file),  the  interaction  with  a  diverse  set 
of  applications  (e.g.  electronic  mail,  configuration  man¬ 
agement,  editor)  and  creation  of  scripts  to  easily  perform 
repeated  sequences  of  tasks.  For  these  tasks,  the  developer 
must  describe  the  action  to  be  performed  via  the  command 
language  provided  by  the  host  system.  The  developer  must 
leave  the  paradigms  of  Ada  and  the  Ada  development  envi¬ 
ronment  and  adopt  the  paradigms  supported  by  the  com¬ 
mand  language. 

Rather  than  require  the  developer  to  learn  and  operate 
under  two  different  paradigms,  Ada  and  that  of  the  par¬ 
ticular  command  language,  the  Ada  Command  Environ¬ 
ment  supports  a  single  paradigm — Ada.  Ada  is  both  the 
programming  language  and  command  language  with  ACE. 
The  paradigm  of  Ada  that  is  familiar  in  the  programming 
development  environment  is  also  the  mechanism  used  to 
interact  with  the  underlying  system  in  the  other  various 
tasks  performed  by  the  developer. 


2  ACE  Overview 

The  Ada  Command  Environment^]  is  an  interactive, 
object-oriented  command  language  environment  for  Ada 
software  development.  ACE  supports  Ada  as  the  program¬ 
ming  language  and  the  command  language.  The  command 
environment  of  ACE  is  defined  through  a  set  of  Ada  ab- 
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Environment  Abstract  Data  Type* 


Ada 

Window 

File 

Compiler 

System 

System 

Application 


Ho* l  Operating  System 


Ada  Command  Environment 


street  data  type*  which  encapsulate  the  host  environment 
into  »o  A<U  framework.  ACE  |«mide*  a  portable  common 
command  language  user  interface  (hot  currently  run*  on 
Son  workstation  and  the  Unisys  l'\V2/500-kn  Intel  802$fi 
based  personal  computer  running  MS-DOS.  With  Ada  a* 
the  command  language,  the  environment  may  he  easily  ex¬ 
tended  And  tailored  through  the  definition  o(  additional 
ADTs  viA  A«1a  statement*. 

ACE  5*  composed  of  two  logically  separate  parts— *n  Ada 
interpreter  And  a  set  of  Ada  package*  th»t  define  the  en¬ 
vironment  through  abstract  data  type*.  The  Ad*  com¬ 
mand  interpreter  provide*  An  inter  Active  execution  of  Ada 
statement*  »nd  compiUtion  unit*.  The  interpreter  in  ACE 
serve*  a*  the  engine  for  preceding  the  command  language 
and  driving  the  Ada  software  develop n vent  proce**.  Ada, 
a*  a  command  language,  is  u*ed  to  invoke  operation*  and 
to  manipulate  environment  object*.  Environment  object* 
arc  expressed  at  Ada  data  type*,  and  command*  are  ex- 
prated  a*  operation*  on  the  data  type*.  Ada  package*  arc 
u*ed  to  group  data  type*  and  operation*  into  abstract  data 

type*. 

■ 

ACE  allow*  a  *  mvon  tel  of  Ada-oriented  object*  ami  op- 
eratioo*  to  be  defined  and  implemented  on  a  diverge  tel 
of  platform*.  ACET  abstract  data  type*  enc*p*u!a(c  tlic 
object*  and  operation*  into  appropriate  u*er  abstraction*. 
The  implementation  of  ACE's  ADT*  allow*  ACE  to  be 
easily  ported  to  a  heterogeneous  set  of  boil  environment*. 

3  Abstract  Data  Types  and  ACE 

Data  abstraction,  information  hiding,  modularity,  and  lo¬ 
cality  are  tome  of  the  the  modern  toftware  engineering 


principle*  used  In  the  development  of  toftware  applica¬ 
tion*.!!)  The  notion  of  data  abstraction  I*  also  a  powerful 
mechanism  for  the  definition  of  a  command  environment— 
an  environment  that  contain*  a  set  of  objects  upon  which 
a  group  of  command  operation*  act. 

An  «Mr*ci  data  type'**  an  abstraction  mechanism  that  en- 
rapsulatc*  a  set  of  value*  together  with  a  set  of  operation* 
that  apply  to  the  valuc*.[2)  Within  software  development, 
the  decomposition  of  the  *y*tcm  may  be  defined  through 
a  set  of  objects,  live  operation*  applicable  to  tins  object*, 
and  tlve  operation*  needed  by  live  object*.  ADT*  serve 
a*  a  natural  description  method  for  this  type  of  system 
decomposition.  ADT*  are  also  a  key  component  of  the 
object-oriented  design  and  development  approach. 

Tlve  directive*  issued  by  a  software  developer  to  the  un¬ 
derlying  liott  environment  may  also  be  naturally  defined 
through  the  u*e  of  ADT*.  Each  directive  or  command  may 
be  viewed  ax  an  operation;  the  qualifier*  or  parameters  may 
be  viewed  a*  the  object*  upon  which  the  operation  is  per¬ 
formed.  Ixvgically  associated  object*  and  operation*  may 
be  gathered  together  into  collection*  which  are  related  to 
particular  components  of  the  underlying  host  environment. 
Thus,  a  parallel  can  be  drawn  between  abstract  data  type* 
and  the  composition  of  a  command  language. 

Many  of  the  newer  procedural  language*  provide  syntactic 
mechanisms  to  easily  sjvecify  and  manipulate  ADT*.  Ada 
is  one  sudi  language.  The  construct*  of  package*  (specifica¬ 
tion  and  body),  subprograms  (functions  and  procedure*), 
subprogram  invocation,  type  declarations,  object  declara¬ 
tions,  and  context  clause*  are  examples  of  Ada's  support 
for  ADTs.  The  Ada  Command  Environment  makes  use 
of  these  Ada  constructs  to  define  the  environment  object* 
and  operation*  through  ADTs. 
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ACE  provide  an  Ada  ADT  interface  to  the  underlying 
host  environment  in  the  form  of  Aria  package  specifica¬ 
tion*.  Tire  package  specifications  are  processed  hy  ACE 
upon  initiation.  Thu*,  a  act  of  predefined  type*  and  ojier* 
ation*  arc  made  available  to  the  u#cr  from  the  beginning 
of  an  ACE  session.  Since  these  tyjvcs  and  ojvcration*  arc 
defined  via  the  Ada  package  construct,  the  method*  u#cd 
to  manipulate  Ada  package*  arc  a!*o  u*cd  to  manipulate 
the  operation  of  the  environment  ADT*. 


4  Benefits  of  the  ACE  Approach 

The  combination  of  ADT*  ami  Ada  provide  many  benefit* 
in  a  command  environment.  Ada  provide*  a  xtrong  lan¬ 
guage  foundation  for  the  conjunction  and  uxc  of  ADT*, 
and  ADT*  provide  the  mechanism  for  environment  manip¬ 
ulation.  The  following  xectionx  describe  the  unique  fea¬ 
ture*  (above  and  beyond  normal  command  language*)  of 
the  ACE  approach. 


4.1  The  Ada  Language  Standard 

Ada,  as  a  modern  procedural  language,  cncomjwuxc*  many 
of  the  xtatc-of-the-arl  software  engineering  principle*. 
These  principle*  arc  extender!  into  the  command  environ¬ 
ment  through  the  use  of  Ada  to  define  the  environment 
with  ADT*. 

The  Ada  package  construct  supports  the  principle*  of  data 
abstraction  and  information  biding  through  the  separation 
of  the  package  specification  from  the  package  body.  Tire 
separation  of  the  specification  and  implementation  of  the 
abstract  data  type  in  Ada  and  ACE  i*  a  key  element  in 
the  ability  to  tailor  the  environment.  Different  implemen¬ 
tations  of  an  environment  ADT  specification  are  an  obvi¬ 
ous  mechanism  for  tailoring  the  environment  to  a  project's 
taste.  For  example,  a  common  configuration  management 
interface  may  be  defined  through  a  single  ADT  sjiecifica- 
lion,  but  different  implementations  may  be  written  based 
upon  the  project's  particular  selection  of  a  configuration 
management  application  system. 

The  ability  to  layer  ADTs  within  Ada  supports  tire  prin¬ 
ciples  of  modularity  and  locality.  Environment  extensibil¬ 
ity  may  be  accomplished  through  tire  use  of  layered  AD  1  >. 
For  example,  a  new  ADT  specification  may  be  written  that 
presents  an  interface  that  is  more  familiar  or  comfortable  to 
the  user.  Tire  implementation  of  that  ADT  simply  invokes 
the  standard  set  of  operations.  The  ADT  makes  tire  trans¬ 
lation  from  user  orientation  to  system  orientation,  rather 
than  forcing  the  human  to  mentally  perform  the  transla¬ 
tion.  Layered  ADTs  also  support  the  notion  of  different 
levels  of  abstraction.  For  example,  the  notion  of  format¬ 
ting  a  textual  document,  building  its  table  of  contents,  and 


printing  the  result  on  a  printer  may  he  viewed  a*  either  a 
single  ©iteration  or  a  series  of  lower  level  operation*.  Low 
level  ADT*  serve  a*  the  building  block*  for  higher  level 
ADTs. 

Within  the  language  definition  of  Ada,  Ada  is  used  to 
extend  it*  own  definition.  The  Ada  input-output  opera¬ 
tion*  (chapter  14  of  the  reference  manual]?))  arc  provided 
in  the  language  by  the  means  of  preslcfittcd  packages.  In 
addition,  other  predefined  library  package*  arc  required  for 
each  Ada  implementation.  ACE  ha*  implemented  the  Ada 
predefined  package*,  such  as  Standard,  ASCII,  Calendar, 
Syataa,  and  T«t  Jo.  This  set  of  package*  make*  the  stan¬ 
dard  Ada  type*  and  operations  available  in  the  command 
environment.  Continuity  it  established  between  the  com¬ 
mand  environment  and  the  typical  Ada  development  envi¬ 
ronment. 

ACE  also  view*  the  set  of  Ada  predefined  |>ackagcx  defined 
in  the  reference  manual  as  a  set  of  guideline*  to  l>c  followed 
in  the  development  of  environment  ADT*.  The  inpul- 
output  package*  of  chapter  14  of  the  reference  inanual[7) 
denote  a  style  of  o|>cralion  definition  and  manipulation 
that  ACE  has  expanded  to  encapsulate  the  entire  envi¬ 
ronment.  The  Croats,  Open,  Close,  and  Deists  proce¬ 
dures  that  arc  applicable  to  file  objects  are  used  within 
the  command  environment  to  define  similar  control  opera¬ 
tion*  upon  other  type*  of  object*.  An  example  of  tin*  is  the 
similar  treatment  of  file  object*  and  window  objects.  File 
objects  and  window  objects  arc  each  abstract  data  types 
in  ACE  that  arc  created  using  the  Croats  procedure  and 
removed  using  the  Deists  procedure.  The  o|>eration*  that 
the  Ada  developer  is  familiar  with  in  the  program  develop¬ 
ment  environment  are  the  same  Deration*  that  .“.:e  to  be 
invoked  within  the  host  environment  to  accomplish  similar 
tasks. 

The  guideline*  arc  followed  in  more  detail  than  simply 
through  subprogram  name*.  Names  ami  modes  of  |>aram- 
cicrs,  ttic  selection  of  a  procedure  versus  a  function,  and 
the  use  of  the  Torn  parameter  as  a  string  data  type  to 
specify  non-default  implementation  options  are  all  further 
examples  of  following  the  style  of  Ada  as  defined  in  the 
language  standard.  These  and  other  instances  of  confor¬ 
mance  within  ACE,  enforce  an  Ada-oriented  style  of  ADTs 
within  the  ACE  environment. 


4.2  Command  Structure 

Consistency  and  uniformity  in  the  command  environment 
of  ACE  is  achieved  through  the  use  of  Ada  and  ADTs. 
Commands  and  objects  are  logically  grouped  together  as 
ADTs  via  the  Ada  package  mechanisms.  This  grouping  al¬ 
lows  tiic  environment  to  be  structured  and  ordered.  In  ad¬ 
dition,  by  nesting  packages  and  subprograms  ttie  environ¬ 
ment  provides  controlled  access  to  information.  Users  ex¬ 
plore  tlie  environment  in  an  orderly  and  informative  man- 


328  7th  Annual  National  Conference  on  Ada  Technology  1989 


tier.  ThU  logic*}  grouping  of  environment  con>|>onenU  ha* 
many  benefit*  over  the  il»t  structure  supported  by  mo*t 
cotnm»ml  language*. 

For  example,  if  a  specific  windowing  package  is  nested  in¬ 
side  *  b*si<  windowing  package,  novice  users  must  ‘use” 
or  reference  the  basic  windowing  package  lieforc  they  can 
access  the  S|>ccific  windowing  package.  This  docs  not  guar¬ 
antee  that  novice  users  understand  the  environment.  How¬ 
ever,  it  docs  guarantee  that  novice  users  understand  the 
logical  structure  of  the  environment.  Of  course,  cX|»erl 
users  who  know  the  structure  of  the  environment  are  not 
hindered,  since  they  can  simply  reference  an  arbitrarily 
nested  command  via  the  Ada  expanded  name  feature. 

Another  lienefit  of  this  command  structure  combined  with 
Ada  is  the  ability  to  define  a  user  interface  that  is  consis¬ 
tent  with  the  paradigms  of  Ada,  as  well  as  uniform  in  its 
treatment  of  objects  and  operation*  in  the  environment. 
Such  an  environment  would  support  (at  all  levels  of  inter¬ 
action  with  the  environment)  Ada  philosophies,  providing 
an  excellent  vehicle  for  Ada  development.  The  facilities 
of  overloading  and  derived  subprograms  in  Ada  provide 
tbc  op|>orluuity  to  define  uniform  interfaces  to  logically 
related  operations  and  objects.  As  described  above,  the 
ability  to  define  a  Create  operation  for  each  type  of  envi¬ 
ronment  object  is  supported  in  Ada  through  overloading. 
ACE  supports  overloading  to  allow  the  uniform  definition 
of  abstract  data  tyjies  across  the  entire  command  environ¬ 
ment.  In  addition  to  being  consistent  with  the  Ada  stan¬ 
dard,  the  environment  is  also  uniform  among  the  ADTs 
that  arc  defined  within  it. 


4.3  Command  Applicability 

One  benefit  of  modern  procedural  languages  is  tbc  notion 
of  strong  typing.  The  benefits  of  strong  typing  within  Ada 
are  also  of  benefit  to  Ada  as  a  command  language  ami  the 
definition  of  ADTs.  While  ADTs  allow  tbc  definition  of  op¬ 
erations  for  objects,  strong  typing  enforces  the  proper  use 
of  the  operations.  Many  of  the  problems  associated  with  a 
novice’s  use  of  a  command  language  can  be  attributed  to 
the  application  of  operations  to  inappropriate  objects  (e.g., 
printing  a  binary  image).  In  a  strongly  typed  command 
language,  and  in  particular  ACE,  if  there  is  no  operation 
“print"  defined  for  binary  image  objects  then  the  user  can 
not  (even  accidentally)  apply  the  operation. 

Another  benefit  of  strong  typing  in  a  command  language 
is  in  the  operation  of  very  large  software  systems.  Many 
of  the  benefits  of  using  ADTs  in  the  construction  of  these 
software  systems  arc  retained  in  the  command  language 
which  acts  as  the  “glue"  which  holds  such  systems  together. 
Having  a  strongly  typed  command  language  helps  guaran¬ 
tee  that  the  systems  arc  correctly  constructed  from  their 
components.  In  addition,  having  a  compilable  command 
language  allows  an  interpreted  system  to  become  an  en¬ 


tirely  compiled  system  merely  by  compiling  the  command 
language,  whereas  in  a  traditional  command  language,  the 
"glue"  would  have  to  be  rewritten  into  the  system’s  pro¬ 
gramming  language. 


Through  the  use  of  derived  types  and  derived  subprograms, 
new  objects  can  be  described  as  specialization*  of  existing 
objects,  i.c.,  described  as  differences  from  existing  objects. 
For  example,  the  entire  abstract  data  type  for  A  CD's  hi¬ 
erarchical  file  system  is  constructed  of  existing  ADTs  that 
are  specializations  of  a  general  file  ADT.  The  general  file 
ADT  provide*  the  basic  operation*  (e.g.,  Create,  Delete, 
Copy,  etc.)  that  can  be  jwrformcd  on  all  files. 

The  immediate  specialization*  of  the  general  file  ADT  arc 
Text  .Files,  Directory  .Files,  and  Binary.Fil*s.  Each 
of  these  specialization*  provides  specific  new  or  redefined 
operstion*  for  each  type.  Any  operation  defined  for  the 
general  file  ADT  that  is  not  redefined  in  a  specialization's 
operation*  is  inherited  by  the  specialization.  Therefore, 
each  socialization  of  the  general  file  ADT  inherits  the 
Create,  Delate,  etc.  operations,  which  in  turn  allows  ev¬ 
ery  type  of  file  in  the  file  system  to  be  manipulated  via  the 
general  file  0|>cr*lion*.  Socialization  provide*  a  very  j>ow- 
erful  reuse  mechanism  within  ACE;  existing  object*  can  be 
extended  or  tailored  for  particular  applications  or  user  aes¬ 
thetics  without  having  to  describe  tbc  entire  ADT. 

In  addition,  since  Ada  (and  consequently  ACE)  implicitly 
derives  subprograms  for  every  derives!  type,  much  of  the 
work  that  Is  normally  associated  with  strong  typing  in  a 
command  language  ami  the  construction  of  a  hierarchical 
command  environment  is  removed  from  the  user.  Each 
derived  type  implicitly  inherit*  a  set  of  command*  that 
enable  its  basic  manipulation. 


An  important  part  of  any  state-of-the-art  environment  is 
the  ability  of  the  environment  to  evolve  as  technology  and 
methodologies  evolve.  ACE’s  approach  is  to  use  Ada  ADTs 
to  define  the  command  language  (creating  a  command  en¬ 
vironment).  As  described  before,  Aria  ADTs  have  a  clean 
separation  of  implementation  from  specification.  There¬ 
fore,  as  technology  makes  small  leaps,  the  new  techniques 
can  be  incorporated  in  the  ADT  implementation  while  not 
effecting  lire  specification.  In  addition,  when  radical  break¬ 
throughs  arc  made  in  technology,  new  environment  ADTs 
can  be  constructed  and  incorporated  into  tbc  command 
environment.  Using  this  approach,  we  arc  only  limited  by 
the  ability  of  Ada  to  assimilate  new  approaches. 


4.4  Command  Specialization 


4.5  Command  Extensibility 
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5  ADT  Interfaces  within  ACE 

Abstract  data  types  within  ACE  arc  defined  by  Ad*  pack¬ 
ages.  The  package  specification*  encapsulate  the  definition 
of  the  object*  ami  the  operation*  that  are  applicable  to  the 
object*.  Additionally,  the  package  specification  provide*  a 
mechanism  for  information  hiding  particularly,  hiding  of 
the  operations'  implementation*.  The  Ad*  package  body 
contain*  the  implementation  of  the  object  and  it*  respec¬ 
tive  operations. 

ACE  supports  two  mechanism*  for  the  implementation  of 
the  ADT  bodies:  inUrpnttd  and  built-in.  Doth  of  these 
mechanisms  support  a  different  facet  of  environment  defi¬ 
nition,  and  together  they  provide  the  facilities  to  compose 
and  extend  the  Ada  command  environment.  Additionally, 
ACE  through  it*  ADTs  provides  a  mechanism  to  acces* 
executable  image*  external  to  ACE.  This  provides  added 
power  and  flexibility  to  the  command  environment. 


5.1  ADT  Body  Implementations 

As  previously  stated,  Ada  is  the  command  language  ac¬ 
cepted  by  ACE  ami  interpreted  by  ACE’s  command  Ian- 
guage  interpreter.  The  environment  (as  defined  as  Ada 
packages)  is  read  by  the  command  language  interpreter 
and  processed,  resulting  in  the  elaboration  of  Ada  pack¬ 
ages.  Tills  process  of  interpreting  Ada  ADT  package  spec¬ 
ifications  and  liodics  is  the  typical  method  through  which 
ADTs  are  declared  within  ACE. 

ACE  provides  an  additional  mechanism  by  which  package 
bodies  may  lie  defined.  Rather  than  interpreting  an  Ada 
package  body,  the  Ada  code  may  be  compiled  and  linked 
into  the  ACE  executable.  The  package  specification  for 
the  package  is  soil  Ada  code  that  is  interpreted  by  ACE. 
A  pragma  directive  informs  ACE  that  the  package  body  as¬ 
sociated  with  this  package  specification  is  already  compiled 
and  included  within  ACE. 

This  method  of  package  body  inclusion  provides  benefits 
to  the  runtime  efficiency  of  ACE.  ACE  may  be  tuned  such 
that  frequently  invoked  code  is  executed  at  the  machine 
language  level  (i.c.,  the  compiled  level),  rather  than  inter¬ 
preted. 

Another  benefit  of  compiled  implementation  is  that  it  pro¬ 
vides  interactive  invocation  ami  composition  of  compiled 
code  within  the  command  environment.  An  example  of 
this  is  the  X  Window  System  ADT  of  ACE  which  pro¬ 
vides  Ada  interfaces  to  the  X  Window  System  (currently 
implemented  in  C;  see  section  C). 


5.2  Extern*!  Image* 

A  vast  array  of  applications  and  support  tools  arc  typi¬ 
cally  available  within  the  host  environment.  AGE  does 
not  impose  a  restrictive  environment  that  limits  the  facil¬ 
ities  available  to  the  software  developer.  Through  a  host 
operating  system  ADT,  ACE  provides  an  interface  mecha¬ 
nism  which  makes  external  executable  images  on  the  host 
system  available  from  within  the  command  environment. 
Thus,  environment  ADT  sjiecificatloiis  are  able  to  define 
a  consistent  Ada  paradigm  for  the  user  that  may  interface 
with  a  diverse  set  of  Ada  and  non-Ada  external  images, 
including  tiie  host  operating  system. 

The  ability  to  access  external  images  provide*  the  oppor¬ 
tunity  to  build  high  level,  Ada  abstractions  from  low  level, 
non- Ada  applications.  Relationships  may  be  formed  among 
stand-alone  applications,  providing  a  higher  level  data  ab¬ 
straction  Dial  encompasses  the  user’s  desired  functional¬ 
ity.  The  intricacies  and/or  idiosyncrasies  of  the  individual 
applications  are  hidden  from  the  user  in  the  ADT  imple¬ 
mentation.  The  implementation  also  hides  the  handling 
of  intermediate  result*  being  passer)  between  application*. 
The  user  simply  sees  the  specification,  which  i*  designed 
to  provide  a  consistent  interface  within  the  Ada-oriented 
environment. 

Ry  invoking  external  images  through  environment  ADT*, 
the  functionality  of  ACE  can  he  extended  into  domains 
which  can  be  tailored  to  specific  environments,  projects,  or 
users.  For  example,  a  project-oriented  configuration  man¬ 
agement  ADT  can  l>c  defined  which  provides  software  con¬ 
figuration  control  objects  and  operation*.  The  programs 
which  must  be  accessed  to  supiiort  these  facilities  may  ex¬ 
ist  scattered  about  the  file  system,  or  |>crhaps  in  a  common 
directory  with  many  other  programs  unrelated  to  configu¬ 
ration  management  tasks.  The  configuration  management 
ADT  can  provide  a  coherent  view  of  these  operations  and 
hide  the  organization  or  disorganization  of  the  underlying 
programs. 


6  X  Window  System  Example 

This  section  describes  the  use  of  abstract  data  types  to  in¬ 
terface  to  the  X  Window  System.  The  X  Window 
Systcin['l],  or  simply  X,  defines  a  window  system  protocol, 
with  which  client  applications  and  window  system  servers 
communicate.  For  application  programmers  to  make  use  of 
X,  a  set  of  library  routines  (Xlib)  and  a  set  of  higher  level 
programmable  interfaces  (toolkits)  are  necessary.  Ada  in¬ 
terfaces  to  the  Xlib  routines  and  toolkits  have  been  imple¬ 
mented  that  allow  Ada  applications  to  make  use  of  X[8). 
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ACE  contain*  *  set  of  ADT*  that  provide*  interactive  ac¬ 
cess  to  the  X  Window  System  routine*.  This  permit* 
AGE  to  be  used  a*  a  rapid  prototyping  environment  for 
the  development  of  X  application*.  Interactively,  window* 
may  Ins  created  and  destroyed,  event*  processed  ant!  prop* 
agated,  and  graphical  element*  manipulated  within  win* 
dow*. 

The  ACE  ADT*  for  X  support  each  window  a*  a  *epa* 
rately  instantiated  window  object.  Once  a  window  object 
ha*  been  declared  and  elaborated,  a  *ct  of  ©iteration*  may 
lie  applied  to  each  window  object.  The  window  object  anti 
the  applicable  *el  of  operation*  are  defined  through  ACE 
ADT*.  Thc*o  ADT*  cor»i*t  of  Ada  package  specification* 
anti  bodies.  The  majority  of  the  package  implementation 
consists  of  interfacing  with  the  Ada  binding  to  the  X  Win* 
dow  System. 

The  X  Window  System  provides  an  excellent  example  of 
using  ADT*  to  tailor  the  Ada  command  language  to  an 
individual  or  project'*  perspective.  The  X  Window  System 
is  described  and  defined  through  a  *cl  of  terminology  that 
i*  based  on  window  system  concept*  and  the  direction*  of 
the  dcvclojiers  and  implementor*  of  X.  X  wa*  designed  to 
be  hardware,  ©(icrating  system  ami  language  indejiemlciU. 
hence  the  names  of  operation*  within  the  X  library  ami 
the  X  toolkit*  arc  couched  in  window  system  terminology. 
Thi*  terminology  may  be  flavored  with  the  implementor's 
primary  target  environment  dialect  a*  necessary. 

ACE  defines  two  set*  of  X  Window  System  ADT*  within 
the  standard  ACE.  Doth  of  these  support  X  in  an  Ada  en¬ 
vironment,  hut  with  different  terminology.  One  set  of  X 
Window  System  ADTs  is  defined  using  X  terminology;  the 
other  set  of  ADTs  i*  defined  in  Ada  terminology.  An  exam¬ 
ple  of  difference*  between  X  terminology  and  Adaterininol* 
ogy  i*  in  the  operation*  used  to  instantiate  a  new  window 
and  to  terminate  an  existing  window.  Using  Ada  termi¬ 
nology  these  operations  are  named  Croat*  and  Dalata,  re¬ 
spectively.  These  name*  were  chosen  because  they  arc  user! 
in  Ada  to  define  similar  operation*  when  applied  to  exter¬ 
nal  files  in  Atla’s  file  management  packages.  This  supports 
the  notion  of  a  single  paradigm  to  the  user— -Ada,  where  all 
operations,  including  those  with  other  applications,  arc  de¬ 
fined  and  invoked  in  a  consistent,  uniform  manner.  Using 
X  terminology  these  operations  are  named  Craata.Vindov 
and  DaatroyJlindov,  respectively,  to  conform  more  closely 
to  the  standard  names  found  in  the  X  Window-  System. 
This  permits  users  who  arc  more  familiar  with  X  to  oper¬ 
ate  in  an  environment  in  which  they  arc  more  comfortable.5 

iftote  that  lh«e  do  not  conform  exactly  to  the  C  Xlib  interface 
routine  name*  of  ICraataViadowand  XD«itroyVindo».  Since  ACE  is 
an  Ada  environment,  the  X  name*  were  slightly  modified  to  resemble 
typical  Ada  subprogram  name*.  If  the  desire  were  to  sup[>orl  a  C- 
oriented  interface  to  Xlib,  an  ADT  could  eaiily  be  defined  that  would 
tupport  the  C  Xlib  interface. 


Each  of  these  two  abstraction*  are  specified  within  ACE 
through  ADT*.  The  user  may  then  *elcct  which  abstrac¬ 
tion  i*  most  appropriate  for  llm  particular  circumstance. 
Direct  visibility  of  the  desired  set  of  operation*  may  bo 
acepfitrd  by  i*stilng  a  “tise"  statement  for  the  re*|>ectivc 
package. 


7  Conclusion 

The  Ada  Command  Environment  provide*  a  command  lan¬ 
guage  that  i*  Ada  and  supports  an  ADT  view  of  the  un¬ 
derlying  operating  system  attd  application  tool*.  Through 
an  ADT  definition,  uiiirptc,  hetcrogenou*  system*  may  bo 
presented  to  a  user  in  a  uniform  and  consistent  descrip¬ 
tion.  The  specification*  of  the  ADT  remain  constant  across 
heterogenous  environments  (machines  and  ©iterating  sys¬ 
tems),  with  different  implementation  of  the  ADTs  to  ac¬ 
comodate  environmental  differences.  The  ADT  approach 
encompasses  the  paradigm*  of  the  Ada  language  and  ex¬ 
tend*  the  prograininimg  language  approach  into  the  user’s 
typical  interactive  environment. 
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Abstract:  Dqtunxmaiion  >«c  uiuatly  txc«di  prt^ram  Hi «  in  ma*i 
ii**m  bun  th «  sffen  in  and  «|anu«  itx  uclmokw 

And  wthmqixi  of  tfcxum«MAikm  am)  e(  jumidlng  uwU  (at  K» 
pttparAUon  amt  U*  to*  l<  smalt  compand  to  that  applied  to 
prorrammlne  This  pap*f  tltsrnhti  an  effort  to  develop  an  Ionova- 
live  approach  to  th*  entry,  worage,  manipulation,  am)  pr«s«ntation 
o(  at  wowed  teat,  graphics,  and  (orma)  (both  apeclfitation  am) 
programs)  tkcumentatlon  whielt  entrances  tire  efficiency  and  effec¬ 
tiveness  of  the  authors  am)  users  of  tlte  documemation 

Our  approach  to  tlx  creation  of  the  documentation  environment 
provides  a  framework  based  on  three  concepts;  itx  documentation  Is 
itruetunJ.  and  therefore  some  of  tlx  semantics  can  be  captured, 
manipulated  by  ihc  computer,  and  Used  to  assist  tlx  creator  and 
user*  of  the  documentation  in  tlxtr  tasks;  the  structure  of  the 
documentation  can  be  captured  In  a  formal  specification,  allowing 
significant  pans  of  tbc  system  to  be  methodically  or  even  automati¬ 
cally  generated;  am)  the  documemation  environment  Iras  an  nr- 
ehliectutt  which  centers  around  a  semantic  database  of  typed  ob¬ 
jects,  relationships  among  objects,  and  semantic  functions  defining 
properties  of  objects.  Tlx  database  and  applications  programs  arc 
generated  from  formal  specifications  of  the  classes  of  objects,  yield¬ 
ing  a  set  of  Ada  packages.  Tltls  paper  describes  the  documemation 
environment's  architecture,  explores  Its  use,  am)  Ulustrawi  the  tech¬ 
nique  of  generating  the  database  and  applications.  A  companion 
paper  describes  she  development  of  one  of  tlx  applications  and  ex¬ 
perience  with  tlx  use  of  the  technique. 

Introduction 

While  documentation  usually  far  exceeds  program  eode  in 
size  in  mosi  systems,  ihc  effort  to  understand  and  or¬ 
ganize  the  technology  and  techniques  of  documentation 
and  of  providing  tools  for  its  preparation  and  its  use  is 
miniscule  compared  to  that  applied  to  programming.  This 
paper  describes  an  R&D  effort  to  develop  technology  for 
preparation,  maintenance  and  use  of  textual,  graphical 
and  formal  documentation  in  an  integrated  fashion  within 
an  advanced  Software  Engineering  Environment.  The 
paper  describes  an  innovative  approach  to  the  entry, 
storage,  manipulation,  and  presentation  of  structured  text, 
graphics,  and  formal  (both  specification  and  programs) 
documentation  which  enhances  the  efficiency  and  effec¬ 
tiveness  of  the  authors  and  users  of  the  documentation. 

The  approach  taken  here  to  the  creation  of  the 
documentation  environment  (a  documentation  environment  is 
analogous  to  the  combination  of  VI,  TROFF,  PIC,  MS,...  of  Unix') 
provides  a  framework  for  its  construction  based  on  three 
concepts;  the  documentation  is  structured,  and  therefore 
some  of  the  semantics  can  be  captured,  manipulated  by 


the  computer,  ami  used  to  assist  the  creator  and  users  of 
the  documentation  In  their  tasks;  and  the  structure  of  the 
documentation  can  be  eaptured  in  a  formal  specification, 
allowing  significant  parts  of  the  system  to  be  methodically 
or  even  automatically  generated;  and  the  documentation 
environment  has  an  architecture  for  which  centers  around 
a  semantic  database  of  typed  objects,  relationships  among 
objects,  and  semantic  functions  defining  properties  of  ob¬ 
jects.  The  database  is  generated  from  a  formal  specifica¬ 
tion  of  the  classes  of  objects,  yielding  a  set  of  abstract 
data  type  packages,  in  Ada,  whose  types  arc  instantiated 
to  form  the  database.  Activities  using  the  database  arc 
methodically  developed  as  applications  programs  using 
the  specifications,  with  parts  of  them  generated  from  the 
specifications  enhanced  by  semantic  functions. 

This  paper  first  discusses  the  concept  of  structured 
documentation  then  describes  the  documentation  environ¬ 
ment's  architecture,  explore  its  use,  and  illustrate  the 
technique  of  generating  the  database  and  applications.  A 
companion  paper  describes  the  development  of  one  of  the 
applications  and  experience  with  the  use  of  the  teehniqtie. 


Structured  Documentation 

When  a  document  is  written,  the  author  has  in  mind  an 
organizational  pattern  of  the  contents  along  with  the  stan¬ 
dard  organizing  structure  of  the  type  of  document  being 
written.  Rcatiers.  likewise,  look  for  both  typographic  and 
semantic  organizational  patterns  which  arc  either  implicit 
in  the  flow  r-f  the  material  or  explicit,  providing 
cucsiMois]  to  the  author's  intended  organization  of  the 
material.  Documentation  has  structure,  a  significant  part 
of  a  reader's  ability  to  understand  a  document  is  the 
ability  to  discern  the  author's  intended  structure  and  then 
to  understand  the  contents  of  the  document  within  that 
framcworkiJonsjjj. 

Everyone  knows  that  documents  have  structure,  the 
last  paragraph  of  the  introduction  of  this  paper,  along 
with  its  section  headings  trys  to  expose  this  paper's  struc- 
ture(Mcyss),  so  the  issue  is  not  whether  documents  have 
structure  but  rather  whether  the  documemation  develop¬ 
ment  environment  should  have  knowledge  of  that  struc¬ 
ture  and  if  so  how  does  it  get  that  knowledge  and  what 
use  can  it  make  of  it. 
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The  idea  of  using  (he  structure  of  a  document  to  assist  nel  caPturc  *he  structure  in  a  way  whieh  allows  the 

in  the  automation  of  the  document's  preparation  began  storage  system  to  provide  access  to  that  structure  to  other 

with  the  StribetKcMi  system  which  separated  the  work  of  ^or  0I*,er  PurP°scs  *kan  printing, 

the  author  from  that  of  the  document's  designer.  Scribe  In  order  to  provide  this  integration  and  semantic  sup- 

provided  the  author  with  structure  describing  commands  port,  we  must  look  to  the  technology  areas  where  high 

to  use  to  delineate  the  structural  parts  of  the  document;  quality  systems  with  these  characteristics  have  been 

these  commands  were  interspersed  with  the  test  in  the  developed.  Concepts  and  facilities  to  provide  the  integra- 

input  to  the  Scribe  system,  which  was  prepared  with  a  text  lion  we  need  have  been  developed  in  the  database  field 

editor.  More  recently,  the  LaTcX  iutt|  system  has  and  thus  we  base  our  architecture  on  the  concept  of  an 

provided  a  similar  eabability  as  a  macro  package  to  the  integrated  documentation  database.  The  major  advances 

TeXtKi.ni  document  preparation  system  and  SGML  isomlj  in  the  area  of  semantic  support  for  automation  have  been 

has  defined  a  standard  external  transmission  form  for  made  in  compiler  research  and  thus  we  base  our  np- 

electronically  transmitting  and  printing  documents  using  proach  on  the  use  of  the  structure  and  techniques  of  corn- 

similar  concepts.  All  of  these  systems  are  "batch"  sys-  pliers.  The  architecture  and  its  implementation  based  on 

terns  producing  the  printed  output  document  directly,  and  these  techniques  from  database  and  compiler  technology 

completely,  form  the  textual  input.  They  allow  the  author  arc  discussed  in  the  rest  of  the  paper.  The  architecture  is 

to  encode  the  structure  of  the  document  in  the  text  but  discussed  in  the  next  section,  followed  by  a  description 

they  do  not  capture  that  structure  in  a  form  which  allows  and  analysis  of  the  usage  of  this  type  of  environment 

processing  other  than  printing.  along  with  the  advanced  functionalities  made  possible  by 

The  Etudeiiumin  system,  and  its  deccndcnt  Inter-  ,his  °uppr®?c',;i  A  d“cript,io"  of  thc  *«»plcn1emation  ap- 

leafi»r<sj|,  provided  interactive  editing-formatting  based  proac'  'Vl  *  follow  that  and  then  an  example  will  illustrate 

on  this  structural  paradigm  by  integrating  an  interactive  met  10d  and  show  lts  advantages, 

formatting  system  into  an  editing  system.  The  Interleaf  Documentation  Environment  Architecture 
system,  on  which  this  paper  was  created,  provides  a  well 

engineered  “what  you  sec  is  what  you  gel”  (WYSIWYG),  The  overall  structure  of  the  environment  (Figure  1)  is  that 

interface  providing  the  structuring  commands  in  an  un-  of  a  database  systcmiDAPSE).  a  central  database  of  struc- 

obtrusive  manner  by  function  keys  and  menu  selections.  tured  objects,  which  ore  of  numerous  types,  worked  on  by 

While  all  of  these  systems,  progressively,  provide  authors  people  in  various  roles,  performing  appropriate  activities, 

with  easy  to  use  document  preparation  systems,  they  do  creating,  manipulating,  and  using  collections  of  objects 

not  provide  the  integration  of  information  storage  and  and  their  components,  through  presentations  of  those  ob- 

processing  nor  the  semantic  assistance  which  is  provided  jetts  made  available  through  appropriate  views  on  thc 

for  programming  by  the  best  integrated  programming  en-  database.  The  types  of  objects  important  for  this  paper 

vironments,  eg.  Smalltalk  and  interlisp.  That  is,  they  do  are  various  types  of  documents,  but  wc  expect  thc  docu- 
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Figure  2  Formatting  Activity 


mcnis  to  be  just  part  of  an  integrated  collection  of  objects 
in  the  environment,  to  include  programs,  test  plans,  for¬ 
mal  specifications,  etc.  in  an  overall  system  database. 

At  its  core,  the  architecture  provides,  a  repository  of 
objects,  along  with  their  properties  and  relationships  to 
other  objects;  and.  as  the  objects  may  be  structured,  it 
provides  for  composition  of  objects  from  sub-objects 
along  with  their  properties  and  relationships.  Collections 
of  objects,  with  subsets  of  their  properties  and  relation- 
ships,  are  presented  to  users  through  views  which  provide 
contexts  for  those  users  to  work.  The  users  arc  involved  in 
some  activities  using  these  views,  with  a  user  behaving  in 
a  role,  known  to  the  environment,  with  respect  to  each 
activity. 

The  database  appears  to  the  users  as  a,  basically  tree 
structured,  collection  of  objects,  defined  by  a  set  of 
abstract  data  types.  These  abstract  data  types  define  the 
abstractions  provided  by  the  views  of  the  database;  the 
implementations  of  the  abstract  data  types  provide  the 
representations  of  the  objects,  in  a  form  chosen  and  op¬ 
timised  by  the  environment’s  administrator^  rote  analogous 
to  that  oi  a  database  administrator).  The  contents  of  objects  are 


displayed  within  windows  on  the  workstation  screen  and 
in  hard  copy  form  through  presentations  of  the  abstrac¬ 
tions  provided  by  the  views. 

The  objects  are  structured  (with  the  overall  wee  oni.ime 
being  provided  by  lire  “is  made  up  oP  relation  of  an  ttb.r-t  i««  its 
components)  with  the  components  of  objects  being  them¬ 
selves  objects,  thus  there  is  no  real  distinction  between 
the  coarse  grained  structure  used  to  describe  the  orJtiiec- 
turc  and  the  fine  grained  structure  of  an  object  visible  to 
an  activity.  This  uniformity  of  concept  provides  a  unifor¬ 
mity  in  the  user’s  interface,  as  well  ns  in  the  user’s  con¬ 
ceptualization  of  the  system;  the  uniformity  assists  the 
user  at  both  the  surface(syntnctic)  and  the  dccp(semantic) 
level.  Making  use  of  this  uniformity,  a  preview  of  the 
main  example  to  be  presented  later  will  illustrate  the  ar¬ 
chitecture. 

The  formatting  activity  (Figure  2)  produces  typeset 
text  from  textual  input  annotated  by  formal 
markup(sgml),  in  this  case  using  the  LaTcX  markup  lan¬ 
guage.  The  input  is  one  of  the  presentations  of  the  docu¬ 
ment  being  processed,  being  presented  and  edited  in  the 
LaTeX  language.  It  is  interpreted  by  the  environment  as  a 
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concrete  syntax  tree  structured  by  the  LnTeX  concrete 
grammar.  U  is  transform ed  Into  the  abstract  syntax  tree 
stored  in  the  database  and  that  is  then  transformed  into 
the  typeset  document  un-O  tt  x.-fi.retc  nntsx  »«ei  defined 
by  the  document'*  design  iwtwh  «  snee-ded  m  Ok  dc>£*'» 
v^ictc  grammar  i.  The  d-cumeni'x  logical  structure  is 
shown  in  the  figure  as  the  indented  li«i  between  the 
presentations  of  the  two  concrete  syntax  trees  The  nor¬ 
mal  method  of  use.  as  shown  by  this  example,  is  the 
manipulation  and  use  of  presentations  domed  frm  the 
abstract  structured  object!*)  stored  in  the  database. 

Implementation  of  this  architecture  rests  on  a  collec¬ 
tion  of  specifications  of  the  abstractions,  their  representa¬ 
tion,  and  their  presentations  Abstractions  arc  specified 
through  abstract  grammars,  presentations  through  con¬ 
crete  grammars  and  representations  through  data  struc¬ 
tures.  These  specifeaifons  are  processed  into  abstract  data 
type  definitions,  transformations  of  objects  from  their 
abstract  type  to  or  front  one  of  the  concrete  types,  and 
implementations  of  the  abstract  and  concrete  types, 
through  a  methodical  technique  developed  in  the  compil¬ 
ing  community  and  described  in  the  section  on  Formal 
Specification  and  Software  Generation. 

Usage  of  the  documentation  environment,  structured 
according  to  this  database  architecture  will  be  covered  in 
the  next  section,  showing  some  of  the  advantages  and  in¬ 
novations  of  this  approach.  The  methodical  implementa¬ 
tion  technique  will  then  be  described,  showing  how  the 
database  and  its  activities  can  be  specified  and  the 
software  implementing  it  ean  be  methodically,  or  even 
automatically,  derived  from  those  specifications.  After 
that,  example  activities,  providing  the  formatting  of  struc¬ 
tured  text,  will  be  described,  illustrating  the  approach. 

Documentation  Environment  Usage 

The  database  orientation  of  the  environment  provides  the 
well  known  advantages  of  information  sharing,  organiza¬ 
tion  and  control,  but  the  enhanced  concept  used  here  also 
provides  for  assistance  in  performing  work  on  a  system's 
development,  and  functionality  just  not  possible  in  non- 
automated  systems.  We  will  illustrate  the  capabilities  of 
the  environment*  by  showing  the  devclopm-.nt  and  use  of 
parts  of  an  example  of  the  developer's  documentation  of 
an  embedded  computer  system|stopl).  We  will  first  show 
the  information  entry  and  storage,  illustrating  the  infor¬ 
mation  organization  capabilities  of  the  system  and  show¬ 
ing  how  this  approach  provides  assistance  to  the  user  in 
performing  necessary  functions.  We  then  illustrate  the  ad¬ 
vanced  functionality  made  possible  by  this  approach  by 
making  use  of  the  fine  structure  of  the  documentation  and 
relationships  among  components  of  that  structure  to 
provide  a  hyper-media  browsing  capability  for  the 
documentation. 

*  As  ihU  Is  a  technology  development  project,  some  ports  exist  in  a  finished 
form,  some  parts  are  In  a  prototype  form  and  some  parts  only  exist  in  conceptual 
design  form. 


The  example  wc  will  use  is  the  developer's  documen¬ 
tation  ef  a  small  embedded  computer  system  using  a  style 
adapted  by  ustwsui  front  that  used  en  the  A-?  project  at 
NRListu-!.  The  hard  copy  form  of  this  example  is  avail- 
able  in  Ada  UttcrsiwM*.  wwt-j.  The  entry  ©f  the  cements 
of  the  documentation  is  done  through  the  use  of  a  format¬ 
ting  language  or  a  structure  editing  system  generated 
from  a  structural  specification  of  the  logical  structure  of 
the  documentation,  wc  will  illustrate  both. 

Text  entry,  using  the  formatting  language,  takes  tex¬ 
tual  input  interspersed  with  logical  markup  commands, 
for  example,  the  beginning  ef  the  behavior  section  ef  the 
system  specification  would  be  input  as. 

\*r  -ippilght  e<*ntrul  Systea  Bchxvter  S vbsys 
lea) 

MublCencsptusl  Uedel) 

vpar  This  Slept ight  Control  Software  Subsyaiea 
Specif Icstlen  uses  a  conceptual  ncdel  of  the 
behavior,  a  state  eachine.  for  estivation  in 
understanding  the  functioning  of  the  systea 
anti  as  a  frase*ork  to  describe  the  functioning 
of  the  systea.  The  stoplight  control  systea 
can  be  understood  as  a  finite  state  machine 
whose  states  are  the  coaMned  states  of  an 
approach  for  each  direction,  each  of  which  can 
he  eepty  or  occupied,  and  a  light  which  can  be 
red.  yellow  or  green  in  each  direction.  The 
traffic  flow  in  the  intersection  controls  the 
values  Of  the  approach  states  and  the  systea 
adjusts  the  light  states  to  control  the 
traffic. 

\sub(Systea  Behavior) 

\par  The  behavior  of  the  Control  Software  Is 
specified  as  a  \cn(fln!ie  state  nachlne)  in 
terss  of  the  following  concepts: 

\lnp{Thero  aro  two  \kw(Dlrections) .  na=ed 
\ea(ii_S)  and  \ea(E_W] 

An  vkw(Approach)  for  each  \kw(di reel ion) 
which  cay  bo  \ee{Occupied)  or  \ea(Ccpiyj, 

A  \kw(Light)  for  each  \kw{direciion)  which 
cay  bo 

\ea(Red),  ven(YeHow)  or  Ves(Crcen). 

A  \kw(Switch)  labeled  Vea(Off),  \es{On)  or 
\ea{Not_Worklng) .) 


Given  the  meaning  of  the  commands,  (\sec » section,  \sub  » 
subsection,  \par  ■  paragraph,  Mnp  =  indented  paragraph,  \kw  ■* 
keyword,  Sent »  emphasized  text)  this  inpul  would  be  parsed  io 
place  the  conients  into  a  structured  object  in  the  database, 
as  will  be  shown  in  the  next  section,  and  that  object  could 
then  be  formatted  to  produce  the  following  output: 
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4.  Stoplight  Control  System  Behavior  Subsystem. 

4.1  Conceptual  Model. 

This  Stoplight  Control  Software  Subsystem 
Specification  uses  a  conceptual  model  of  the  be¬ 
havior,  a  Mate  machine,  for  motivation  in  under¬ 
standing  the  functioning  of  the  system  and  as  a 
framework  to  describe  the  functioning  of  the  sys¬ 
tem  «  The  stoplight  control  system  can  be  under¬ 
stood  as  a  finite  state  machine  whose  states  are  the 
combined  states  of  an  approach  for  each  direction, 
each  of  which  ean  be  empty  or  occupied,  and  a 
light  which  ean  be  red,  yellow  or  green  in  each 
direction.  The  traffic  flow  in  the  intersection  con¬ 
trols  the  values  of  the  approach  states  and  the  sys¬ 
tem  adjusts  the  light  states  to  control  the  traffic 

4.2  Systom  Behavior. 

The  behavior  of  the  Control  Software  Is 
specified  as  a  finite  state  moehine  in  terms  of  the 
following  concepts: 


Wnen  filled  in,  it  would  enter  the  information  in  the 
bibliographic  database  and  attach  a  reference  relation  to 
the  test  segment. 

Formal  Specification  -  Software  Generation 

The  idea  of  methodically,  even  automatically,  generat¬ 
ing  programs  from  specifications  started  with  the  “struc¬ 
tured  programming''  methods  of  Jackson;;***;  and 
\VirihiWu*«i  in  the  mid  seventies.  Here,  one  would  define 
the  data  structures  which  a  program  needed  to  work  and, 
from  the  natural  correspondence  between  data  structures 
and  program  structure  ut  atrsjv  cwitijvfij  m  ic*f>rc* 
v-uropsml  w  K<Kk»>  the  program’s  structure  would  be 
methodically  derived.  The  automatic  generation  of  both 
data  structures  and  program  structure,  in  the  limited 
domain  of  programming  language  compilers,  came  into 
being  with  the  eompiler-eompilers.  at  about  the  same 
timciVACC.  Wrt’tj.  The  extension  of  this  technique  to 
programming  environments  occurred  later  with  the  Can- 
datf;u*n4*uiJi  project  at  CMU  and  the  DaI’SG 
projecuBAKtft.  We  arc  extending  the  DAl'SE  approach 
into  the  (structured)  documentation  area. 


There  arc  two  Directions, 
named  N_S  and  EJV 
An  Approach  for  each  direction 
which  may  be  OceupkJ  or  Empty. 

A  Light  for  each  direction  which  may  be 
Red,  Yellow  or  Green. 

A  Switch  labeled  Off.  On  or  AT’MI’erJtfng, 

Which  has  the  same  logical  structure  as  the  input,  with 
the  concrete  syntax  considerably  und  uufult,)  different- 

structure  editors  have  a  knowledge  of  the  logical 
structure  of  the  objcct(s)  they  ore  editing.  This  knowledge 
Is  provided  to  the  editor  in  the  form  of  a  specification  and 
is  presented  to  the  user  in  the  form  of  help  or  assistance 
in  the  entering  and  manipulating  of  the  contents  of  the 
object.  We  will  illustrate  this  by  showing  the  use  of  a  form 
based  reference  editor  for  entering  bibliographic 
references  in  the  text.  For  instance,  when  attaching  a 
bibliographic  reference  to  a  segment  of  text,  a  window 
with  a  form  based  editor  would  appear  on  the  user's 
screen;  it  would  request  the  type  of  reference  (journal 
paper.  book,  «te.)  and  then  prompt  for  the  contents: 


The  specifications  are  written  in  an  attribute  gram- 
marikMM  notation  ami  a  combination  of  methodical  and 
automatic  generation  of  the  database  and  programs  is 
used  to  construct  the  environment  facilities  (methodical 
generation  I*  u»ed  ut  ptatmvpe  a  function.  it, -iking  nut  die  detail*  xj 
that  an  automatic  tool  can  tie  generated) 

The  technique  is  best  explained  by  illustration:  sup- 
pose  it  is  desired  to  make  a  system  which  formats  text, 
including  subscripts,  ie.  an  input  of  E  sub\  ,val  should 
produce  Ei.val.  Using  this  technique,  we  would  write  an 
attribute  grammar!,  specifying  the  structure  and 
functionality  of  the  system: 

S  B; 

(B.ps  :■  10} 

(S.hi :«  B.ht) 

B  111  112; 

(lll.ps  :■  B.ps} 

(B2.ps  :■  B.ps} 

(B.ht  :■  max(Bl.ht,  B2.ht)) 

B  Bl  J»6  B2 

(Bl.ps  :■  B.ps) 

(B2.ps  :«  shrink(B.ps)} 

(B.ht :«  displBl.ht.  H2.ht» 

II text 

(B.ht  :-  tc.xt.ht  X  B.ps) 

Where  S  «  segment,  B  ■  block,  ps  «-  point  size,  hi  - 
height,  shrink  «  function  to  calculate  the  size  of  a  numeral 
when  used  as  a  subscript,  disp  «  function  to  calculate  the 
height  of  two  boxes  displaced  vertically,  and  (nttr  :=  val} 
is  an  attribute  semantic  function 


1  We  limit  the  turamsr  heie  la  s[»e.if)int  the  height  iitcuUiion  foi  slms'h.tiy 
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'litis  grammar  is  methodically  transformed  Into  a 
storage  definition  module  (net*  that  n  u  <J<r.n«a  In  tlu«e 
pit-Coitions  H  >  BB.  It  -»  B>ubt).  ami  It  text!  which  con¬ 
tains  the  following  data  types  to  store  Block  nulca: 

t\(X  Is  tBtiDtt.  BuBsubB.  Bl»Textt, 

tv|K>  BjMlejMfltcnu  iVatKtt  B j>»i>du£tton-.» aticty  iBuTcmi. 
type  B.notlc  Is  aescss  B.nadejMMcMs 
Ujte  Bjiudejumtenu  (Variety  Bj'roUuctwfl.xarKiy  utl.'Texii 
Is  recent 

hi  height;  —  jjnrtr -astJ  attribute 

pi  pi>im_*ire;  —•  InheiiteJ  attribute 

case  Variety  Is 

when  thsllt)  <o  HI.  Ill:  ll.noJe;  -II  ■  III) 
when  Ilutl nil'll  *>  fll.  III  I1_iukJ<,--W  Ihubl) 
when  UijTcxi  »>  text  Mnng.  —Hu  ten 
textjt  height;  —Int/tmk 

enil  ease: 
end  reeoril: 

and  a  function  module  which  provides  the  following  func¬ 
tion  to  process  Block  nodes: 

function  B  t  Bn  U_noJe.  Iln_pi  potni.ruel  return  height  Is 
begin 

case  Un  Variety  Is 

when  n»nn  ■>  Bn.BI.pt  Bnj!!.  —  an tirnuJ 

Un.D2.pi :»  lln_p!.--  tiit/n  >■/  tiiiJnn 
Dn.ht  :■  inaxt  Utltn.Ill,  Hn.Dl.ptl, 
HtUn.112.  Dn.It2.pl  1). 
— •  talmlatt  nnrlbuiets)  «f  self 
when  DuDiul'D  *'-Dn.Bl.ps  .«  Dn_pi; 

Dn.D2.ps  :»  shrink!  Djpsl; 

Dn.ht  ;b  diipt  IltDn.Bl,  Dn.Dl.pi). 

lltDn.D2.  Dn.D2.ps  )); 

when  DisText  =>  Dn.ht  :=  Dn_pt  *  Bn.texiJrj 
end  case; 

return  t  Bn. hit;  —  return  synthesis*  J  oltributetsl  of  self 
end  B: 


Automatic  generation  of  software  proceeds  similarly, 
with  top  down  generators  producing  recursive  data  struc¬ 
tures  and  functions  similar  to  those  illustrated  above, 
definite  clause  grammars  in  PROLOG!*)!*!,  or  tables 
similar  to  those  used  in  |Wn:*i,  Bottom  tip  generators 
using  table  driven  techniques  similar  to  those  used  in 
IVACcj.  The  approach  to  developing  systems  using  this 
technique  is  illustrated  in  figure  3. 

lv,\atii|)le 

We  will  illustrate  the  documentation  environment  and  its 
construction  by  developing  the  structure  of  a  component 
of  the  environment,  the  subsystem  which  transforms  tex¬ 
tual  input  into  a  structured  document  ir.  the  database  and 
transforms  that  document  into  typeset  output.  This  func¬ 
tion  can  be  viewed  ns  a  batch  formatter  ns  illustrated  in 
figure  ‘I.  but  in  our  npproach  it  is  viewed  as  the  three 
components  that  were  illustrated  in  figure  2:  a  translator 
from  the  textual  concrete  syntax  hi  the  abstract  syntax,  n 
database  to  store  the  abstract  syntax,  and  a  translator 
from  the  abstract  syntax  to  the  output  concrete  syntax. 

The  database  to  store  the  abstract  syntax  is  generated 
from  a  specification  of  the  abstract  structure  of  a  docu¬ 
ment,  ns  is  shown  on  the  right  hand  side  of  figure  5, 
which  specifics  the  productions  showing  the  components 
of  the  objects  which  make  up  a  document  along  with  their 
attributes  (in  italics).  This  generates  the  type  definition 
modules  out  of  which  the  database  is  constructed  by  the 
parsing  function;  the  database  resulting  from  inputting  the 
example  document  is  shown  on  the  left  side  of  figure  5. 
The  parsing  function  is  generated  front  a  concrete  gram¬ 
mar,  such  ns: 

Document  (Title.  Author,  Abstract,  Text,  References) 
Tide  “Mi"  Texi 
Author  “\nu"  Text 
Abstract  ::■»  “\ab"  Text 
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Figure  6  Environment  Structure 


along  with  the  abstract  grammar  producing,  for  example, 
recursive  procedures  like: 

procedure  DOCUMENT  (  D:  out  Documcnt_Structure)  is 
begin 

If  Next_Tokcn  »  **\tiM  then 

TITLEf  T);  —  reads  tide  string  into  T 
elslf  Ne.\t_Token  ■  ‘’Nau”  then 

AUTI  IOR(  A);  —  reads  author  string  into  A 
•  •  • 
end  if; 

D  :■  Mnke_Document_Node(  T,  A,  ...);  —  uses 
—  abstract  grammar  to  construct  node 
end  DOCUMENT; 

when  the  recursive  decent  generation  technique  is  used. 
The  unparser  is  generated  similarly,  walking  the  tree  like 
the  function  “B"  above  rather  than  scanning  the  input  like 
"DOCUMENT”  does. 

The  main  advantages  cf  this  archii.-.ture  are  the  op¬ 
portunities  for  reuse  of  the  subfunctions  which  become 
manageable  entities  in  the  architecture,  the  productivity 


advantages  of  the  software  generation  approach  fostered 
by  the  architecture,  and  the  opportunities  for  providing 
Innovative  functionalities  made  possible  by  it.  As  an  ex¬ 
ample  of  the  reuse  and  productivity  advantages,  a  SOME 
exporter  is  a,  relatively  simple,  tree  walking  unparser 
which  can  be  generated  from  the  ast  grammar  specifica¬ 
tion  and  a  SGML  concrete  grammar  specification,  figure 
6,  white  a  SGML  importer  is  a  parser  similar  to  the 
LnTeX  parser.  As  an  example  of  the  provision  of  innova¬ 
tive  functionality,  consider  a  WYSIWYG  document  entry 
system,  in  this  architecture  it  is  a  combination  of  on  un¬ 
parser,  similar  to  the  typesetting  unparser,  along  with  a 
parser  of  that  concrete  syntax,  figure  6.  A  final  example 
of  innovative  functionality  is  a  hyper-text  browser  which 
can  be  implemented  as  a  menu  based  system  which 
provides  a  menu  entry  for  each  relation  from  a  node,  fol¬ 
lows  that  relation  to  its  destination  node  upon  selection 
and  displays  the  destination  node  using  the  WYSIWYG’s 
unparser. 
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Conclusions 

The  eapturing  of  the  structure  of  the  documentation  in  the 
documentation  environment  presents  many  advantages.  In 
the  providing  of  advanced  functionality,  in  the  flexibility 
of  system  and  In  th-i  productivity  of  the  development  and 
system  evolution  process.  The  documentation  environ¬ 
ment  project  Introduced  here  has  shown  that  the  architec¬ 
ture  and  approach  described  arc  feasabtc  and  desirable, 
leading  to  high  quality  high  functionality  systems. 
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ABSTRACT 

The  goal  of  this  project  was  to  investigate 
the  application  of  compiler  technology  to  the 
development  of  an  Integrated  documentation 
generation  system.  A  prototype  text  formatter 
was  developed  as  a  demonstration  of  the 
application  of  this  technology  to  such  a  system. 


1.0  INTRODUCTION 

Once  a  system  has  been  designed  and 
developed,  it  is  often  the  supporting 
documentation  that  is  of  the  greatest  concern  to 
the  developer.  The  required  documentation  is 
very  often  neglected  due  to  schedule  ovemms. 
An  integrated  environment  with  tools  to  support 
the  user  would  be  a  very  desirable  system.  As 
such,  it  was  decided  to  design  and  implement  a 
text  formatter  using  aspects  of  the  existing 
compiler  technology.  This  text  formatter  was 
treated  as  a  prototype  subsystem  of  the  overall 
envisioned  system  and  was  attempted  mainly  to 
investigate  the  application  of  this  technology  to 
the  area  of  documentation  engineering. 

The  text  formatter  wi;  designed  to  be  a 
batch  system  and  acts  mainly  as  a  filter.  From 
the  user's  point  of  view,  the  system  reads  in  an 
input  file,  acts  on  it  (as  indicated  by  the 
appropriate  commands  contained  within  the 
document),  and  produces  some  output.  An 
ASCII  editor  is  needed  to  enter  the  text  in  a  file. 
Commands  are  to  be  used  to  achieve  the  desired 


format.  These  commands  would  be  provided  in  a 
User's  Manual. 

Since  this  project  was  to  investigate  the 
application  of  compiler  technology,  a  context-free 
grammar  was  first  defined.  An  intermediate 
representation,  the  Abstract  Syntax  Tice,  was 
then  decided  upon.  Following  this,  attributes 
were  chosen  and  the  scanner  and  parser 
designed.  These  arc  discussed  in  the  following 
sections.  It  must  be  noted  that  the  overall 
system  is  not  restricted  to  a  formatter.  Once  the 
intermediate  representation  is  known,  several 
applications  may  be  developed  based  an  the 
structure  of  this  representation.  This  may  be 
done  by  producing  different  back-end  code 
generators.  As  such,  several  subsystems  may 
be  developed  and  integrated  as  part  of  an  overall 
environment. 


2.0  COMPILER  DESIGN 

This  section  provides  some  background  on  the 
aspects  of  compiler  structure  that  were  deemed 
to  be  of  importance  to  this  project.  The  main 
phases  of  a  compiler  (4)  are  the  following : 

(a)  Scanner :  The  function  of  the  scanner 
is  to  read  in  characters  from  a  source  file  and 
produce  tokens  as  an  output.  These  tokens  are 
defined  by  the  context-free  grammar. 

(b)  Parser:  The  parser  reads  in  the 
tokens  produced  by  the  scanner  and  sorts  them 
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into  groups  based  on  the  productions  defined  in 
the  context-free  grammar. 

(c)  Semantic  Routines  :  Semantic 
routines  check  the  semantics  of  the  constmets 
and  perform  a  translation  by  producing  an 
intermediate  representation. 

(d)  Code  Generator :  lire  intermediate 
representation  produced  by  the  semantic  routines 
is  then  convened  into  some  target  machine  code. 
As  such,  if  code  were  needed  for  a  different  target 
machine,  only  the  back-end  code  generator  would 
have  to  be  changed. 

This,  very  briefly,  describes  the  structure 
of  a  compiler  and  is  shown  in  Figure  1. 


Figure  1  Structure  of  a  Syntactic  Compiler 


3.0  CONTEXT-FREE  GRAMMAR 

A  context-free  grammar  was  first  defined 
for  this  project  as  this  would  influence  the  design 
of  the  parser.  An  LL(1)  type  grammar  was 
decided  upon  as  this  would  facilitate  top-dewn 
parsing.  This  grammar  utilized  the  idea  of 
productions  or  rules  for  the  system  followed  by 
terminals  (the  right-hand  side  of  a  production) 


and  non-terminals  (the  left-hand  side  of  a 
production).  All  non-terminals  are  first  resolved 
into  terminals  by  the  system  before  proceeding 
and  this  is  done  as  defined  by  the  appropriate 
production.  As  such,  by  knowing  the  productions 
and  recognizing  a  valid  non-terminal,  the  system 
knows  what  should  follow.  This  grammar  Is 


described  as  follows 

2 

<Documeni> 

<Titl»  <Date> 
<Author>  <Sections> 

<Titlc> 

••> 

<Un»  (  <line> ) 

<Line> 

••> 

Char_«String 

<Daic> 

-•> 

Char_String 

<Author> 

••> 

<Line>  (  <Linc> ) 

<Sections> 

*•> 

<Scc_Tiilc> 

(  <Paragraphs>  ) 

{ <SubScctions> ) 

<Scc_Tille> 

••> 

Char_Siring 

<Paragraphs> 

••> 

<Block>  { <B!ock> ) 

<SubSections> 

••> 

<SubSec_Titlo 
{  <Paragraphs>  ) 

<SubSec_Title> 

Char_String 

<B!ock> 

--> 

Char_String 

The  <  >  brackets  indicate  a  non-terminal 
which  must  be  resolved  into  terminals.  The 
braces  {  )  denote  optional  items  from  0  onwards. 
Associated  with  the  grammar  defined  above  are 
attributes.  These  attributes  arc  associated  with 
certain  terminals  and  non-terminals.  These  are 
shown  below : 


HEM  ATTRIBUTE 

Paragraphs  Indent  of  three  spaces 
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Scctiorvjntle  Section.No 

(Generated  by  system) 


StibScc_Titlc  SubSec_Tit!c_No 

(Generated  by  system) 

Char_String  Font,  Size,  Quality, 

Underline,  Bold 


Appropriate  default  settings  arc  provided  for 
the  attributes. 


4.0  SYSTEM  DESIGN 

The  design  of  the  system  consisted  of  the 
Scanner,  the  Parser,  and  the  Code  Generator. 
This  was  consistent  with  the  effort  to  explore 
compiler  technology  as  a  development  technique 
for  the  system. 


Scanner  :  The  Scanner  follows  the  same 
functionality  as  the  scanner  in  a  compiler 
scheme.  It  consists  of  the  Reader  and  the 
Translator.  The  reader  reads  in  characters  from 
the  input  file  and  the  Translator  converts  these 
characters  to  tokens.  These  tokens  arc  the 
terminals  and  appropriate  commands. 


Parser  :  The  Parser  consists  of  the  Token 
Identifier,  Token  Translator,  Attribute  Manager, 
and  the  Tree  Manager.  The  Token  Identifier 
receives  tokens  from  the  Scanner  and  groups 
them  into  commands  and  attributes.  These 
commands  and  attributes  arc  then  passed  to  the 
Token  Translator.  The  Token  Translator  sends 
the  attributes  to  the  Attribute  Manager  and  the 
commands  to  the  Tree  Manager.  The  Attribute 
Manager  groups  incoming  attributes  into  sets  and 
sends  them  to  the  Tree  Manager.  The  Tree 
Manager  receives  commands  and  sets  of 
attributes  and  creates  the  Abstract  Syntax  Tree 
with  the  appropriate  nodes.  It  then  enters  the 


accompanying  tat  at  the  nodes.  Each  node  has 
certain  attributes  associated  with  it.  These 
attributes  arc  either  set  by  the  user  or  arc 
provided  for  by  default  settings  within  the  code. 


Code  Generator  :  The  Code  Generator 
consists  of  the  Tree  Reader,  Node  Identifier,  and 
the  Node  Translator.  The  Tree  Reader  reads  the 
Abstract  Syntax  Tree  and  retrieves  the  nodes. 
The  nodes  are  sent  to  the  Node  Idcmificr  which 
decides  what  type  of  node  they  arc.  This  node 
information  is  then  passed  to  the  Node  Translator 
which  produces  the  desired  formatted  output. 
The  Code  Generator  is  dependent  upon  the 
application  desired.  There  are  two  generators  for 
this  project.  One  produces  output  targeted  for  an 
IBM  compatible  dot  matrix  printer  while  the  other 
produces  output  in  Postscript. 


The  system  design  is  shown  in  Figure  2. 
and  the  first-level  decomposition  is  shown  in 
Figure  3. 


Figure  2  Tor-Lcvcl  System  Design 
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Figure  3_Breakdown  of  System  Design 


system  was  Ada*.  The  compilers  used  were  the 
Alsys2  Ada  compiler  cm  a  Zenith3  AT  and  the 
Verdix4  Ada  compiler  on  the  Sun5  workstations. 
The  modules  produced  arc  shown  below : 

Packages: 

(a)  Tokcn_Scanner  :  This  package 
encapsulates  the  functions  of  the  Scanner  from 
the  system  design.  It  consists  of  the  procedure 
Open_Rlc  and  the  procedure  Gct.Token. 

(b)  Parser  :  This  package  addresses 
the  functions  of  the  Parser  from  the  system 
design.  It  consists  of  the  procedure  Appcnd_CST. 

(c)  Code_Gcncrator  :  This  package 
contains  the  procedure  Gencrate.Output  which 
provides  the  functions  for  the  Code_Gcncrator 
from  the  system  design. 

(d)  Typc_Dec!araiions  :  This  package 
contains  all  the  data  types  necessary  for  the 
other  packages. 

(c)  Tree  :  This  package  contains  the 
types  necessary  for  the  Parser  and 
Code.Generator  packages  in  order  to  isolate 
these  types  from  the  Scanner,  which  does  not 
need  them. 

Several  types  of  nodes  were  needed  in  the 
Abstract  Syntax  Tree.  The  type  of  node  was 
indicated  by  the  structure  of  the  context-free 
grammar  (eg.  Section  nodes,  Subsection  nodes 
etc.).  These  nodes  then  had  certain  attributes 
associated  with  them.  Discriminant  records  were 
used  to  represent  the  various  kinds  of  nodes. 
The  nodes  were  differentiated  based  on  the 
contents  of  a  field  called  Kind.  The  software  top- 
level  dependency  diagram  is  shown  in  Figure  4. 


S.O  SOFTWARE  DESIGN 

The  software  design  closely  followed  the 
system  design.  The  language  used  to  code  this 


1.  Ada  is  a  registered  trademark  of  AJPO. 

2.  Alsys  is  a  registered  trademark  of  Alsys,  Inc. 

3.  Zenith  is  a  registered  trademark  of  Zenith  Data 
Systems. 

4.  Verdix  is  a  registered  trademark  of  the  Verdix 
Corporation. 

5.  Sun  is  a  registered  trademark  of  Sun  Microsystems. 
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Figure  4  Ada  Package  Dependency  Diagram 


MEN11AKCEMEMXS 

It  must  be  noted  that  the  main  purpose  or 
this  project  was  to  demonstrate  the  use  of  a 
technology  Tor  a  particular  area.  The  system 
developed  was  largely  intended  to  be  a  vehicle  for 
the  purposes  of  demonstration.  If  this  prototype 
were  to  be  further  developed,  the  following 
enhancements  should  be  considered : 

(a)  The  system  could  be  made  interactive 
(WYSIWYG)  and  menu-driven.  This  would 


make  It  more  user-friendly.  The  ability  to  input 
the  productions  desired  and  have  the  scanning 
and  parsing  routines  incorporate  these  rules 
would  make  for  flexibility. 

(b)  An  underlying  database  could  be 
integrated.  The  Abstract  Syntax  Tree  could  then 
be  permanently  stored  in  the  database  instead  of 
being  resident  in  memory.  This  would  allow  for 
the  incorporation  of  roles  within  the  environment. 

(c)  The  technique  of  swapping  could  be 
added  in  order  to  increase  performance. 

(d)  The  option  for  different  output 
generators  could  be  added.  Selection  could  be 
made  from  a  menu.  Thus  the  user  could  choose  to 
obtain  a  printed  copy,  observe  the  formatted  copy 
on  the  screen,  or  achieve  any  goal  for  which  there 
e*!.iii  an  output  generator.  This  would  not  affect 
the  parser  or  the  scanner. 


7.9  CONCLUSION 

This  project  demonstrated  the  porting  of 
compiler  technology  to  a  documentation  system. 
The  major  achievement  is  the  realization  of  the 
Abstract  Syntax  Tree.  Once  the  structure  of  this 
tree  is  established,  several  tools  may  be 
developed  and  interfaced  to  provide  a 
comprehensive  environment. 

This  prototype  was  a  tool  that 
demonstrated  this  fact.  This  tool  could  be  further 
refined  into  a  viable  commercial  product.  From  a 
conceptual  level,  there  were  no  actual  hardware 
or  software  dependencies.  If  output  were  desired 
for  a  different  target  machine  or  purpose,  then 
only  the  Code  Generator  modules  need  be 
changed.  The  sample  commands  used  were 
omitted  from  this  paper.  It  has  been  the  intention 
of  this  paper  to  demonstrate  the  application  of  a 
technology  to  a  certain  area  and  not  to  involve  the 
reader  in  the  details  of  the  prototype.  The 
prototype  has  only  been  discussed  to  the  level 
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which  helps  achieve  this  goal. 
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REDUCING  SOFTWARE  DEVELOPMENT  COSTS  WITH  ADA 


Jeffrey  R.  Curler.  Senior  Engineer.  Software 


Martin  Marietta  Astronautics  Group.  Denver.  Colorado 


Afeita&t 

increases  in  the  abstraction  of  languages 
have  historically  resulted  in  significant  reductions 
in  the  cost  of  software  development  by 
eliminating  or  reducing  software  development 
phases.  These  changes  In  the  software- 
development  lifecycle  have  significantly  reduced 
the  cost  of  software  development  for  Identical 
problems.  Ada  Is  a  significant  increase  In 
abstraction  over  other  languages.  Ada  must 
change  the  traditional  software-development 
lifecycle  If  it  Is  to  provide  a  significant  reduction 
In  software  development  costs.  Comparing  the 
results  obtained  using  the  Martin  Marietta  Ada 
Implementation  Method  with  those  obtained 
using  traditional  methods  demonstrates  that 
using  Ada  with  a  method  which  Incorporates  the 
software  engineering  mind  set  docs  change  the 
lifecycle.  Tills  results  in  a  significant  reduction  of 
software  development  effort  and  cost. 


Introduction 

Increases  in  the  abstraction  of  languages 
have  historically  resulted  In  significant  reductions 
In  the  cost  of  software  development  by 
eliminating  or  reducing  software  development 
phases.  Obvious  examples  Include  using  assembly 
languages  Instead  of  machine  code  and  using 
higher-level  languages,  such  as  FORTRAN,  instead 
of  assembly  languages.  The  former  eliminated  the 
phase  in  which  machine  code  was  determined, 
while  the  latter  significantly  reduced  the  coding 
phase.  Perhaps  less  obvious  is  the  use  of 
high-level  languages  which  contain  a  complete  set 
of  control  structures,  which  eliminated  the  phase 
In  which  a  "structured"  program  design  language 
was  translated  into  the  implementation  language. 
Changes  In  the  software-development  lifecycle 
such  as  these  have  significantly  reduced  the  cost 
of  software  development  for  Identical  problems. 

Ada  Is  a  significant  Increase  In  abstraction 
over  other  languages  |l|.  Ada  has  been  shown  to 
reduce  the  effort  required  to  develop  software 
when  used  as  the  implementation  language  with 
traditional  software  development  methods  (2]. 


However.  Ada  must  change  the  traditional 
software-development  lifecycle  If  It  Is  to  provide  a 
significant  reduction  In  software  development 
costs.  Many  researchers  continue  to  discuss  Ada 
with  the  assumption  that  the  full,  traditlonal- 
iifccyclc  model  is  applicable.  This  assumption  Is 
not  valid,  ns  this  paper  demonstrates.  If  It  were 
true,  using  Ada  would  not  result  In  any  major 
reductions  In  software  costs. 

In  my  work  with  the  Martin  Marietta  Ada 
Implementation  Method  (MMAIM)  [3.  41  I  have 
used  MMAIM  on  a  number  of  problems  which 
occur  frequently  in  the  literature  and  so  have 
been  worked  with  traditional-lifecycle  methods 
for  implementation  In  traditional  languages. 
MMAIM  reflects  and  enforces  the  modern 
software  engineering  "mind  set."  By  comparing 
the  results  obtained  using  MMAIM  with  those 
obtained  using  traditional  methods,  I  can 
demonstrate  that  using  Ada  with  a  method  which 
incorporates  the  software  engineering  mind  set 
does  change  the  lifecycle.  This  results  In  a 
significant  reduction  of  software  development 
effort. 

XhsXnditiCMitrol.Probkm 

The  problem  of  a  cruise  control  for  an 
automobile  occurs  In  nearly  all  the  real-time 
literature.  Ward  and  Mellor  |5]  present  such  a 
problem,  but  It  bears  no  resemblance  to  any  actual 
cruise-control  system  I  have  encountered.  In  this 
paper  I  will  use  a  version  of  the  cruise-control 
problem  to  demonstrate  the  elimination  of 
lifecycle  phases  using  Ada  and  MMAIM. 

The  cruise-control  system  is  Intended  to 
control  the  speed  of  a  car  by  maintaining  a 
constant  speed.  The  controls  for  the  system 
consist  of  a  two-position  switch  labeled  “ofT  and 
"on."  two  buttons  labeled  “set"  and  "resume," 
and  a  sensor  connected  to  the  brake  pedal. 
These  controls  generate  five  unique  Interrupts. 
The  off-on  switch  generates  an  interrupt 
whenever  Its  position  Is  changed;  one  interrupt  is 
generated  when  the  switch  is  moved  to  the  "off” 
position  and  another  when  it  is  moved  to  the 
"on"  position.  The  set  and  resume  buttons  each 
generate  an  interrupt  when  they  arc  pressed. 
The  brake  sensor  generates  an  interrupt  when 
the  brake  pedal  is  depressed. 


348  7th  Annual  National  Conference  on  Ada  Technology  1989 


Tlic  off-on  switch  turns  the  system  off  and 
on.  When  the  system  Is  off  It  has  no  effect  on  the 
car’s  speed,  and  will  only  respond  to  the  system 
being  turned  on.  The  system  Ignores  the  other 
controls.  Note  that  the  software  continues  to 
operate  when  the  system  Is  turned  off 

When  the  system  Is  on.  It  can  be  turned  off. 
or  It  can  be  Instructed  to  maintain  the  car's 
current  speed  by  pressing  the  set  button.  'Hie 
system  Ignores  any  other  controls. 

When  the  system  Is  maintaining  a  speed.  It 
can  be  turned  off.  or  It  can  be  Interrupted  by 
pressing  the  brake  pedal.  The  driver  can  also 
override  the  system  by  pressing  the  accelerator 
pedal.  In  this  case  the  driver  can  have  the  system 
maintain  the  new  speed  by  pressing  the  set 
button.  The  system  Ignores  the  resume  button. 

When  the  system  Is  Interrupted,  it  can  be 
turned  off.  or  it  can  be  set  to  maintain  a  new 
speed,  or  the  resume  button  will  cause  the  system 
to  return  the  car  to  the  previous  speed  and 
maintain  It.  The  system  Ignores  the  brake  pedal. 

Note  that  this  system  has  some 
simplifications  from  an  actual  cruise  control.  For 
example,  there  Is  no  Interaction  with  the  car’s 
transmission.  Real  cruise-control  systems  take 
the  transmission  Into  consideration.  Also,  we  will 
assume  that  the  specific  computer  for  the  system 
allows  the  software  to  Ignore  the  Interrupts  which 
the  controls  generate.  Few  actual  computers 
behave  this  way. 

The  Softyirc-PcrcloBmcnt  Pn?cc»i 

In  tills  paper  I  am  concerned  only  with  the 
software-development  process.  Any  system-level 
concerns,  such  as  hardware-software  partitioning, 
have  already  been  done.  I  am  not  discussing  what 
methods  arc  appropriate  for  dealing  with  system- 
level  concerns. 

Traditional  software-development  methods 
begin  with  a  phase  which  Is  usually  called  analysis, 
specification,  or  systems  design.  One  method 
which  is  widely  used  for  this  software- 
development  phase  Is  real-time  structured 
analysis.  In  tills  section  of  the  paper  1  will  work 
through  the  steps  Involved  in  applying  real-time 
structured  analysis  to  the  cruise-control  software- 
development  problem,  and  compare  this 
traditional  approach  to  MMAIM.  Doth  these 
methods  produce  both  textual  and  graphical 
results.  Since  the  graphical  products  contain 
more  Information.  I  will  concentrate  on  them. 

Step  1-Rcd-nmc-Stmctwcd.Antlyaii 

In  applying  real-time  structured  t  mlysls  to 
the  cruise-control  problem  I  will  use  Ward  and 
Mcllor’s  solution  15)  as  a  guide.  The  first  step  In 
applying  real  time  structured  analysis  Is  to 
describe  the  context  of  the  software.  'Hie  context 
diagram  shows  the  software  as  a  circle  and  the 
things  In  Its  environment  with  which  it  Interacts 
as  boxes.  Solid  arrows  represent  data  flows 
between  the  software  and  the  boxes,  and  dashed 


arrows  represent  control  flows.  Data  flows  arc 
not  associated  with  control  flows.  Working  along 
the  lines  suggested  by  Ward  and  Mcllor  produces 
the  context  diagram  In  Figure  1. 


Crultt  Control  Context  Olagrom 
Figure  t. 


Step  1 -MMAIM 

MMAIM’s  first  step  Identifies  the  software 
boundary,  the  entitles  external  to  the  software 
with  which  it  interacts,  and  the  Interfaces  across 
or  through  the  software  boundary.  These  arc 
shown  on  the  External  Entity  Graph,  or  EEC. 
Figure  2  presents  the  EEG  for  the  cruise  control. 
The  EEG  shows  the  software  ns  a  double-line  box 
and  the  external  entities  as  single-line  boxes. 
The  double-line  arrows  represent  Interfaces 
across  the  software  boundary.  The  direction  of 
the  arrow  represents  the  direction  of  control:  we 
would  say  that  the  software  “calls'  the  throttle 
controller.  This  means  that  the  software  decides 
or  controls  when  it  will  get  or  change  the 
throttle’s  position.  The  small  arrows  associated 
with  the  interfaces  represent  data  flows 
associated  with  the  Interface. 

StepJ-Cqmairitan 

The  first  steps  of  the  two  methods  are  very 
similar.  MMAIM  provides  some  Information  not 
given  by  real-time  structured  analysis:  the 
association  of  data  with  control. 

Step  2-Rcal-Tfmc  Structured  Analyst* 

Real-time  structured  analysis’  next  step 
decomposes  the  software  into  Its  major  functions, 
data  stores,  and  the  data  and  control  flows 
between  them.  Figure  3  Is  the  top-level  data  flow 
diagram  for  the  cruise  control.  The  solid-line 
circles  represent  dntn-transformlng  functions. 
The  dashed-line  circles  represent  control- 
transforming  functions.  Two  parallel  horizontal 
lines  represent  data  stores,  which  usually  mean 
global  or  common  variables.  Note  that,  although 
this  dugram  inherits  arrows  from  the  context 
diagram,  a  single  arrow  on  the  context  diagram 
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Cruls*  Control  External  Entity  Graph 
Figure  2 


SUP.2::MMAIM 

MMAIM's  next  step  decomposes  the 
software  Into  the  major  entitles  of  the  problem. 
These  entitles  arc  software  models  of  physical 
things  and  logical  concepts  In  the  problem  space. 
The  Interactions  between  these  entitles  arc 
Identified  and  the  attributes  of  these  entitles  and 
their  Interfaces  arc  recorded.  This  results  In  an 
Entity  Interaction  Graph,  or  EIG.  The  entitles  on 
an  EIG  arc  initially  assumed  to  be  concurrent. 

The  top-level  EIG  Inherits  the  double-line 
arrows  from  the  EEG.  For  each  external  entity  on 
the  EEG.  a  reusable  entity  Is  created  to  Interface 
with  and  model  the  external  entity.  For  the 
cruise  control,  we  would  create  a  driver  Interface 
entity  which  would  be  connected  to  all  of  the 
external  arrows  connected  to  the  driver  external 
entity.  Similarly,  we  would  create  n  throttle 
controller  Interface  entity  and  a  drive  shaft  sensor 
Interface  entity. 

These  "edge"  entitles  should  fairly  closely 
model  their  corresponding  external  entitles  to 
facilitate  reuse.  For  example,  another  application 
may  use  the  throttle  controller  hardware.  The 
software  for  this  application  should  be  able  to 
reuse  the  throttle  controller  Interface  we  will 


Cruise  Control  Level  0  Data  Flow  Diagram 
Figure  3 


may  be  represented  by  more  than  one  arrow  on 
the  data  flow  diagram. 

Associated  with  data  flow  diagrams  Is  a 
textual  data  dictionary.  It  describes  the  data  flows 
on  the  data  flow  diagrams. 


create  for  the  cruise  control.  Double-line  boxes 
represent  reusable  entitles;  single-line  boxes 
represent  non-reusablc  {application-dependent) 
entitles. 
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The  other  entitles  on  nn  EIG  model  logical 
concepts  In  the  problem.  These  arc  those 
concepts  which  the  software  must  handle 
correctly  In  order  to  work.  The  cruise-control 
problem  has  two  such  concepts.  One  Is  the 
concept  of  the  driver's  Intentions  and  the  other  Is 
the  concept  of  controlling  the  car's  speed.  To 
model  these  concepts  we  would  create  driver 
model  and  speed  controller  entitles. 

Given  the  simplifications  discussed  earlier, 
we  can  see  that  the  driver  Interface  entity  we 
created  serves  no  purpose  and  performs  no 
function.  We  can  obtain  the  same  effect  by 
connecting  the  external  arrows  from  the  driver 
external  entity  directly  to  the  driver  model  entity. 
I  will  do  this  and  call  the  driver  model  the  driver 
Interface  and  model  to  reflect  this.  This  change 
eliminates  the  reusability  concept  for  the  driver 
Interface,  but  1  can't  conceive  or  another  use  for 
these  driver  controls. 

Figure  4  shows  the  resulting  EIG  for  the 
cruise  control.  The  two  reusable  edge  entitles 
closely  model  their  external  entitles.  'Hie  speed 
controller  entity  provides  two  Interfaces.  One 
tells  the  speed  controller  to  start  maintaining 
some  desired  rotation  rate.  The  other  tells  It  to 
stop  controlling  the  car's  speed. 


Ciulit_Cont(ol  Entity  Interaction  Graph 
Flgura  4 


The  speed  controller  needs  to  get  the 
current  rate  so  It  can  compare  It  to  the  desired 
rate.  It  also  needs  to  command  the  throttle 
controller.  The  driver  Interface  and  model  needs 
to  determine  the  rate  which  the  driver  Intends 
that  the  system  should  maintain.  It  also  needs  to 
command  the  speed  controller. 


The  remaining  feature  on  this  graph  Is  the 
small  black  circle  at  the  point  of  some  of  the 
arrows.  Called  "blocks."  these  Indicate  that  the 
logic  of  the  entity  to  which  the  arrow  points 
exercises  control  over  when  It  will  respond  to  a 
call  to  the  Interface.  For  example,  the  speed 
controller  will  not  respond  to  a  call  to  Its  stop 
Interface  when  It  Is  stopped.  However.  It  will 
always  respond  to  a  call  to  Its  maintain  Interface. 

At  this  point  a  search  would  be  made  for 
existing  reusable  software  components  which 
match  the  requirements  for  the  reusable  entitles 
on  the  EIG.  In  many  cases  these  can  be  found. 
Applications  which  obtain  the  time  from  a  real¬ 
time  clock  may  be  able  to  use  the  predefined 
package  calendar,  to  name  one  example.  We  will 
assume  that  none  of  the  reusable  entitles  on 
Figure  4  exist,  and  that  we  will  have  to  develop 
them. 

An  EIG  provides  Interface  specification 
Information.  One  of  the  advantages  of  Ada  Is  that 
It  provides  features  to  represent  Interface 
specifications  separately  from  their  Implemen¬ 
tation.  Ada  Is  not  perfect  In  this  respect.  Ada 
only  represents  Information  about  exception 
propagation  and  blocks,  for  example,  ns 
comments  In  a  specification.  Ada  is  still  a  great 
Improvement  over  languages  such  ns  FORTRAN  In 
this  respect. 

MMAIM  provides  for  mechanical  conversion 
of  an  EIG  to  Ada  code.  By  mechanical  conversion 
I  mean  that  the  EIG  and  Its  associated  attribute 
Information  provides  all  of  the  Information 
provided  by  the  Ada  code,  and  a  machine  could 
perform  the  conversion,  in  this  way  MMAIM  uses 
the  Ada  compiler  to  check  and  enforce  the 
software’s  Interfaces  from  the  very  beginning  of 
the  software-development  process.  This  elimi¬ 
nates  many  problems  with  Integrating  the 
software,  which  Is  a  lengthy  and  expensive  phase 
of  most  traditional  methods. 

Before  Figure  4  can  be  mechanically 
converted  to  Ada  code,  we  must  supply  some 
additional  textual  information  defining  the  data 
types  on  the  EIG  and  the  Ada  constructs  to  be 
used  to  represent  the  entitles.  When  this  has 
been  done.  Figure  4  produces 

package  chrottle_controller  interface  is 
type  position-!*  digits  <T  rang* 

0.0  ..  100.0 

t 

function  get  return  position; 
procedure  put 

(dosired_position  :  in  position) 

t 

end  throttle_controller_interface; 

package  drive  shaft_sensor_interface  is 
typa  rate  £s  range  0  ..*10_0Q0; 
function  get  raturn  rate;  “ 
and  drive  shaft  sensor  interface; 
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vith  drive^shaft^senser  interfaeo; 
procedure  cruise” centre!  i« 

task 

driver  interface  and  nodal 
is  “ 

antry  off; 
antry  an; 

•ntry  set; 
antry  brake; 
antry  rcsur.o; 

and  driver JLnterfaeo_and_niedol; 
task  spoed“cent roller  is~ 
antry  step; 
antry  naincaln 

(desired__race  ;  in 

drive  "shaft  sensor  interface. rare 

) 

# 

and  ppeed^cont roller ; 

task  body^river^lncorfaco^andjnedel 

is  saparata; 

task  body  speedjconcroller 

is  saparata;  ~ 
begin  --  cruise  control 
null; 

and  cruise_concrol; 

All  the  Ada  code  presented  here  has  been 
produced  by  a  (human)  simulation  of  a  simple 
program.  This  results  in  Important  aspects  of  the 
code,  such  as  meaningful  comments,  being 
missing.  I  have  also  omitted  the  Ada  constructs 
which  would  connect  the  entries  of  driver 
interface  and  model  to  thclr  Interrupts,  since  this 
Is  hardware  dependent. 

Now  that  we  have  this  code,  we  can  do 
several  Interesting  things  with  It  before 
continuing  the  software-development  process.  By 
attaching  suitable  stubs,  we  can  perform 
top-down  testing.  Other  stubs  can  produce  a 
prototype  system.  For  large  systems,  parts  of  the 
software  can  be  left  as  stubs  while  the  rest  Is 
completely  developed  and  delivered  as  a  system 
which  provides  partial  but  useful  functionality. 
This  partial  system  may  be  used  while  the 
remainder  of  the  system  Is  developed 
incrementally. 

S.t*P-3-Cgfnp.«it.9ia 

These  two  methods  reflect  two  very 
different  mind  sets.  The  differences  between 
these  two  mind  sets  is  responsible  for  the 
differences  between  Figures  3  and  4.  Finding 
similarities  between  them  Is  difficult.  Both  have 
the  same  data  coming  In  and  going  out  of  the 
software.  The  driver  Interface  and  model  entity 
on  Figure  4  represents  information  similar  to 
circles  1  and  2  on  Figure  3,  as  well  as  the  data 
store.  The  speed  controller  entity  represents 
Information  similar  to  circles  3  and  4.  The  other 
entities  on  Figure  4  have  no  counterparts  on 
Figure  3. 

Since  I  assume  the  reader  is  more  familiar 
with  real-time  structured  analysis  than  with 
MMAIM.  I  have  devoted  more  of  my  text  to 


describing  the  latter  than  the  former,  but  It 
requires  about  the  same  amount  of  time,  effort, 
and  cost  to  develop  a  good  top-level  data  flow 
diagram  as  It  docs  to  produce  a  good  top-level 
EIG.  They  do  require  very  different  mental 
orientations. 

Although  they  cost  about  the  same  to 
produce.  MMAIM  "  Includes  Information  not 
available  with  real-time  structured  analysis,  and 
MMAIM  provides  for  mechanical  generation  of 
Ada  code  very  early  in  the  development  process. 
With  a  suitable  too},  this  code  generation  could  be 
done  automatically.  Tills  gives  MMAIM  the 
potential  to  eliminate  the  coding  phase  of  the 
lifecycle  and  to  significantly  reduce  the 
Integration  phase. 

Step  3-Real  Time  Structured  AnahreU 

On  large  problems,  some  of  the  data- 
transforming  functions  on  a  high-level  data  flow 
diagram  will  be  dccomjioscd  Into  lower-level  data 
flow  diagrams.  The  cruise-control  problem  Is 
simple  enough  that  Figure  3  is  the  only  data  llow 
diagram.  The  data-transformlng  circles  on  Figure 
3  have  textual  “mini-specifications'  associated 
with  them  which  describe  the  function  of  the 
circle  In  greater  detail. 

Control  transforming  functions  on  data  flow 
diagrams  are  not  decomposed,  but  their  behavior 
is  represented  using  a  Mealy-model  state 
transition  diagram.  Figure  5  shows  the  state 
transition  diagram  for  the  control  CC  engagement 
circle  from  Figure  3. 

This  concludes  the  application  of  real-time 
structured  analysis  to  the  cruise-control  problem. 
This  lias  been  the  traditional  analysis  phase  of 
software  development  and  takes  about  twenty 
percent  of  the  total  software-development  effort. 
Real-time  structured  analysis  will  he  followed  by 
the  design  and  coding  phases. 

Step  3-MMAIM 

On  large  problems.  MMAIM  decomposes 
some  of  the  entitles  on  a  high-level  EIG  Into 
lower-level  EIG's.  I  call  these  entitles  “non- 
prlmltlvc."  Cruise  control  Is  simple  enough  that 
Figure  4  Is  the  only  EIG. 

MMAIM's  third  step  for  primitive  entitles 
determines  the  behaviors  which  the  entity 
performs  and  the  conditions  which  determine 
the  transitions  between  these  behaviors.  Ada 
context  Information  and  declarations  required  to 
support  the  behaviors  are  specified.  This 
Information  is  given  by  a  Behavior  Transition 
Graph  (BTG). 

Figure  6  shows  the  BTG  for  the  driver 
interface  and  model  entity  from  Figure  4.  Each 
shape  represents  a  behavior,  except  for  the  two 
top  boxes  labeled  “context"  and  “declarations." 
The  arrows  between  the  shapes  represent 
permissible  transitions  between  the  behaviors.  A 
box  represents  sequential  Ada  code.  A  diamond 
represents  an  unconditional  wait  for  an  event.  A 
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triangle  represents  a  conditional  choice  or 
transitions.  A  circle  represents  a  ncited  BTG. 

The  arrow  from  the  declarations  box  points 
to  the  Initial  behavior.  For  the  driver  Interface 
and  model,  this  Is  an  unconditional  wall  for  the 
"on"  event,  represented  by  a  diamond  labeled 
"on."  Such  an  unconditional  wait  corresponds  In 
Ada  terms  to  waiting  for  a  call  to  the  named  entry. 

When  on  occurs,  the  driver  Interface  and 
model  will  transition  to  the  next  behavior,  'lids  Is 
a  conditional  wait  for  one  of  several  events.  In  this 
case  the  "ofF  and  "set"  events.  The  triangle 
labeled  "accept"  represents  this  conditional  wait. 
In  Ada  terms  this  Is  a  selective  wait.  These 
accept  triangles  can  have  optional  "delay"  or 
"else"  transitions. 

Off  will  cause  the  driver  Interface  and 
madid  to  return  to  the  Initial  behavior.  Set  will 
transition  to  the  sequential  Ada  code  contained  In 
a  rectangle.  Upon  completing  this  behavior,  the 
driver  Interface  and  model  will  unconditionally 
and  Immediately  transition  to  the  next  behavior. 
The  reader  should  now  be  able  to  understand  the 
rest  of  Figure  6. 


Oiiv»rlnttfl*e»  »nd  Modtl  B«h»vlor  Tr»ntlll«n  G»»ph 
Flgui#  I 


The  behaviors  represented  In  Figure  6 
require  Ada  context  visibility  to  the  drive  shaft 
sensor  interface  and  to  the  speed  controller. 
Since  the  Ada  code  produced  from  Figure  4 
provides  that  visibility,  no  additional  context  Is 
required.  We  Indicate  this  by  putting  "null"  In 
the  BTG's  context  box.  These  behaviors  also 
require  a  variable  called  deslrcd_rnte!  It  Is 
declared  In  the  declarations  box. 

As  with  an  EIG.  MMAIM  mechanically 
produces  Ada  code  from  a  BTG.  Froaj  Figure  6  a 
simple  program  can  produce 

separate  (cruise_control J 
task  body  driver" int(?rfaec»_and_wod‘:,l  is 
type  KMAIM_beliavior_id  ill  rang*  1  ..8; 
KMAIM_behavior  :  te'’.AIM_behavior>_id  :■ 

tStAIM^behavior^id'  first 

begin  —  driver__iritorfac._arid_r.odol 
KMAIM  forever:  loop  “ 
case  MMAIM_behavior  is 
whan  1  »>  --  diar.ond  on 
accapt  on; 

KMAIM  behavior  :»  2; 
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wb«n  2  ■>  --  triangle  accept 

select 

accept  off; 

MKA I M_be hftvlur  ;»  1; 

or 

accept  sec; 

MMAIM  behavior  ;*  3; 
end  select; 
when  3  ■>  —  box 
deslrcd_rate  :« 

drivejjha  ft _aensor_inter face . gee 

MMAIM  behavior  :■  4; 
when  4  “>  —  box 

spccd^cencroller.naincair. 

(desircdjrate) 

MMAIMJsehavior  ;■  5; 
when  5  ■>  —  triangle  accept 

select 

accept  sec 

MMAIM  behavior  :■  3; 

or 

accept  off; 

MMAIM  behavior  :■  6; 

or 

accept  brake; 

MMAIMJbehavler  :■  7; 
end  select; 
when  6  ■  »  —  box 

speed  control lor. scop; 
MMAIMJiehavier  1; 
when  7  *>  —  box 

speed_concroller.scop; 
W4AIM_bchavior  ;■  8; 
when  8  ■>  —  triangle  accept 
select 

accept  off; 

MMAIM  behavior  :■  1; 
or 

accept  set; 

KHAIM  behavior  :■  3; 

or 

accept  resume; 
miHJsehavior  :■  4; 

end  select; 

end  case; 

end  loop  MMAIM  ferovor; 
end  drivor_incorfnco_and_r.Qdel; 

Similarly,  wc  can  produce  the  BTG  for  the 
speed  controller  to  obtain  Figure  7.  The  speed 
controller  requires  visibility  of  the  throttle 
cont  oiler  Interface,  so  the  latter  Is  named  In  the 
context  box.  The  speed  controller  also  uses  a 
variable  and  a  procedure  which  arc  declared  In 
the  declarations  box. 

The  only  new  feature  on  Figure  7  is  the 
circle.  It  Introduces  a  nested  (sub-)  BTG.  In  this 
case  the  nested  BTG  Is  the  critical  region  which 
follows  the  "do"  of  an  accept,  indicated  by  the 
label  "do'  in  the  circle.  Nested  BTG's  do  not 
have  a  context  box.  but  may  have  any  other  feature 
of  a  BTG. 

Note  also  the  "else"  transition  from  the 
accept  triangle.  Tills  corresponds  to  an  else 
alternative  of  a  selective  wait. 


SpMd.Conholkr  Behavior  Transition  Graph 
Figure  7 


MMAIM  can  mechanically  produce  Ada  code 
from  Figure  7.  giving 

with  throttle  controller  interface; 
separata  (cruise  control! 
task  body  speed  controller  is 

type  MMAIM  behavior  id  is  range  1  . .  5; 
FKAIMJjchavior  :  MMAIM  behavior  id 
MMAIM_bohavior_id' first  “ 

# 

wantcd_rate  : 

drive_shaft_sensor_intor face. rote 

» 

procedure  maintain  rate 
(desired_rate  :  In 
drive_shaf t_sensor_inter face . rate 

)  is  separate- 

a 

begin  --  speed_controller 
KMAIM_forever  :  loop 
case  MMAIM_behavior  is 
when  l  »>  — -  box 

throttle^oncroller^inter  face,  put 
tdesired_positioiT  ■>  0.0) 

MMAIM_behavior  :«  2; 
when  2  *>  --  diamond  maintain 
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accept  rainrain 

(desired  race  :  in 
drivecfiaft^sens^inccrfacc. 
race 

) 

do 

KMAIM  0C«O(51  :  daclara 

typi  KKMM_fechavl*sr_id  ia 

range  1  .  1 

MKAX.4  Ichavir-r  : 

KKft'XM  behavior  id  :* 
NKfVXMJschavfcr^id  •  first 

bag in  —  KMAIM.COQiU 
KMAXM  forever  :  loop 
cal*  MMMMJrchavinr  i« 
whan  1  »’>  --  bos? 
wanted  rate  :* 
■jesi’red_rate 

exit  KMAXM„f©rever; 

and  cats; 

and  loop  KMAXM  forever; 
and  KMMM.00001;  ” 
and  maintain'; 

KMAXK,bohavier  :■  4; 
whan  3  ■>  —  circle  do 
raiaa  program jsrror; 
whan  4  ■>  —  triangle  accept 
aalact 

accept  maintain 

(de3lred_roce  :  in 
drivo_sRafc_sensor_incerfaee. 
race 

) 

do 

KMAXM  00002  :  daclara 

type  KMAIM_bohavier_ld  ia 
range  1 ~ .  1 

KMAIMJsohavior  : 

KMMM  behavior  id  :■ 

KMMM_behavfbr_id‘  first 

bag'in  —  MMAIMJI0002 
MMAXM„ forever  :  loop 
ccaa  KMAIMJSobavior  ia 
whan  1  ">  --  box 
wanted  race  :■ 
dosrrod_rate 

axit  KMMM_forevcr; 
and  caaa;  ~ 
and  loop  KMAXM  forever; 
and  MMAIM_00002;  “ 
and  maintain; 

MMAIM_behavior  :■  4; 
or 

accapt  scop; 

KMMM  behavior  1; 

alia  “ 

KKMMJbchavior  :*  5; 
and  aalact; 
whan  5  «>  --  box 
maintain_rate 

(desired_rate  =>  wanted_rate) 


KMAXM  kehavicr  :«  4; 

and  caaa; 

and  loop  KMAXM  forever; 
and  speed, cent reller; 

The  ihrottle  controller  Interface  and  the 
drive  shaft  sensor  Interface  arc  dependent  on  the 
hardware  with  which  they  Interact,  so  we  can't 
produce  real  UTG's  for  them  without  knowing 
more  about  the  hardware.  Wc  do  know  enough  to 
outline  the  structure  of  their  UTG's.  which  are 
given  In  Figures  8  and  9. 


Throttl*  Conltolltf  littwhc*  B*h**kx  Ti»ntlilon  Graph 
Flgu<*  • 


Dflv*  Shall  S«n*of  Intarlie*  Sahavlor  Turnlikxi  Graph 
Flgur*  9 
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Similarly,  wc  cannot  product  Ada  code  until 
we  have  the  final  BTC's.  hut  Figure#  8  and  9 
provide  enough  information  that  we  know  the 
structure  of  this  code.  Figure  8  produces 
something  like 

package  body 

chrotcle  controller  interface 

is 

task  MMAXMJiandlee  i# 

•ntry  ger  tetirr4.u jsoaJclen  :  out 
pcs Icier 

1 

t 

•ntry  put  (desired  position  :  in 
position 

1 

end  HMMM_handler; 

function  get  return  position  is 
current  position  :  position; 
begin  —  got 

MMAIMJuindler .  gee 
(currenc^posieien  ■> 
curronejsosieion 

# 

return  current  position; 

•nd  get; 

procedure  put 

(desired  position  :  in  position) 

is 

—  null; 
begin  --  put 

NMAIMJumdler.puc 

(desired jaosicion  ■> 
desirodjmsicion 

s 

•nd  put; 

task  body  MMAIM  handler  is 
--  null; 

begin  —  MMAIMJinndler 
forever  ;  loop 

select 

accept  get 

(current  position  :  out 
position 

) 

do 

—  call  hardware  to  get 

—  throttle  position 
•nd  get; 

or 

accept  put 

(desiredjpcsition  :  in 
position 

) 

do 

—  call  hardware  to  change 

—  throttle  position 
•nd  put; 

•nd  select; 

•nd  loop  forever; 
end  MMAIM_handler; 
end  t.hrottle^controller  interface; 


While  Figure  9  produces  something  like 

package  body  drive  shaft  sensor  interface 
is  "  ~ 

task  MMAIM^handler  is 

•ntry  get  (current  rate  :  out  race) ; 
end  MMAIM_hafidler;  ” 

function  get  return  rate  is 
current  race  :  rate; 
begin  —  get 

KMAlMJiandlar .get 

tevTrrencjrace  ■>  currenc_rate) 

♦ 

return  current  rate; 

•nd  get; 

task  body  MMAIM  handler  is 
—  null; 

begin  —  KMAJMJiandler 
forever  :  loop 
accept  get 

(current  race  :  out  race) 
do 

—  call  hardware  to  get  rotation 

—  rate 
•nd  get; 

•nd  loop  forever; 

•nd  MMAIM  handler; 

•nd  drive_3Hafc_sonsor_interface; 

Except  for  Implementing  the  maintain.ratc 
procedure  wc  declared  In  the  speed  controller, 
this  completes  the  Implementation  of  the 
cruise-control  software.  This  procedure  would 
get  the  current  rotation  rate  and  throttle 
position,  calculate  a  new  throttle  position  front 
them  and  the  desired  rotation  rate,  change  the 
throttle  position,  and  return.  The  details  of  the 
calculation  of  the  new  throttle  position  depend  on 
the  relationship  between  the  throttle  position  and 
the  rotation  rate.  As  this  Is  a  function  of  the 
hardware.  1  will  not  pursue  it  further. 

Step  3-Comptrisoa 

MMAIM  has  created  four  BTG’s  compared 
to  one  state  transition  diagram  from  real-time 
structured  analysis.  This  Is  mainly  due  to  MMAIM 
doing  some  work  at  this  step  which  real-time 
structured  analysis  defers  to  the  design  phase. 

There  arc  some  similarities  between 
Figures  5  and  6.  The  "on“  diamond  of  Figure  6 
corresponds  directly  to  the  "system  off  state  of 
Figure  5.  Similarly,  the  top  accept  triangle 
corresponds  to  the  "system  on”  state,  and  the 
bottom  accept  triangle  to  the  "interrupted"  state. 

There  are  more  differences  than 
similarities  between  the  two.  however.  The 
middle  accept  triangle  of  Figure  6  corresponds  to 
both  of  the  remaining  states  of  Figure  5.  This  is 
because  real-time  structured  analysis'  functional 
orientation  separates  the  veiy  similar  and  logically 
related  functions  of  maintaining  speed  and 
returning  to  a  previous  speed,  while  MMAIM 
combines  them  under  the  higher-level  concept  of 
controlling  the  speed.  This  basic  difference  In 
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the  orientation  of  the  two  methods  nlso  causes 
the  differences  between  the  actions  of  Figure  5 
and  the  remaining  behaviors  of  Figure  6. 

Another  difference  at  this  step,  ns  with  the 
second  step,  is  that  MMAIM  mechanically 
produces  Ada  code  from  BTC's. 

Cost  Com  ptrl  k>c 

Clearly,  using  MMAIM  has  required  more 
effort  than  real-time  structured  analysis  to  reach 
this  point.  Tills  additional  effort  produced  the 
three  BTC's  for  which  real-time  structured 
analysis  has  no  counterparts.  Also,  the  attribute 
Information  associated  with  an  FIG  requires  more 
effort  from  the  developer  to  produce  than  the 
data  dictionary  associated  with  a  data  flow 
diagram.  MMAIM  appears  to  require  about  fifty 
percent  more  effort  than  real-time  structured 
analysis. 

MMAIM  has  completely  Implemented  the 
software,  however,  while  real-time  structured 
analysis  has  barely  started.  Since  the  analysis 
phase  requires  about  twenty  percent  of  the  total 
software-development  effort,  it  appears  at  first 
that  MMAIM  only  requires  thirty  percent  of  the 
traditional  effort  to  complete  implementation, 
providing  a  seventy  percent  savings. 

However,  this  demonstration  has  not 
Included  the  effort  that  must  be  expended  on  real 
projects  for  testing,  documentation,  and 
integration.  Although  MMAIM  effectively  elimi¬ 
nates  software  Integration  problems,  we  stilt 
frequently  sec  problems  Integrating  the  software 
with  the  hardware.  This  reduces  MMAIM’s 
savings  of  effort  to  about  fifty  percent.  Still,  ’half 
price"  Is  a  powerful  Incentive  for  buyers. 

MMAIM  has  a  number  of  features  which 
contribute  to  this  cost  savings.  The  mind  set 
underlying  MMAIM  concentrates  on  such  analysis 
Information  as  major  components  of  the  problem 
and  their  top-level  Interfaces,  compared  to  the 
traditional  emphasis  on  functions  and  data  Hows. 

Adding  top-level  design  Information  to  the 
representation  of  this  analysis  Information 
eliminates  the  translation  effort  traditionally 
required  between  analysis  and  design  notations. 
Coupled  with  Ada's  ability  to  represent  much  of 
this  Interface  specification  information  as 
compilable  Ada  code,  this  allows  coding  and 
testing  to  begin  Immediately,  as  well  as  providing 
enforcement  of  the  Interfaces. 

Finally,  the  ability  to  mechanically  produce 
Ada  code  from  MMAIM  graphs  effectively 
eliminates  the  coding  phase. 

■Conclttflop 

We  have  seen  that  Ada.  when  used  with  a 
suitable  development  method  which  incorporalcs 
the  modern  software  engineering  mind  set, 
changes  the  software  development  lifecycle.  The 
result  Is  a  completely-implemented  system 
without  significantly  more  effort  than  usually  goes 
into  the  traditional  analysis  phase.  In  addition. 


there  should  be  further  savings  due  to  reduced 
maintenance  costs,  and  reductions  In  future 
software  development  costs  due  to  the 
Identification  and  development  of  reusable 
software.  These  cost  savings  are  an  Important 
consequence  of  the  software  engineering  mind 
set.  It  Is  especially  lm|>ortnni  to  note  that  It 
appears  that  not  everyone  who  can  produce 
software  In  traditional  languages,  such  as 
FORTRAN.  COBOL  Pascal,  and  C.  can  develop  this 
mind  set  |1|.  Since  software  costs  are  the 
dominant  factor  In  total  systems  costs,  the  use  of 
Ada  and  the  software  engineering  mind  set  by 
appropriate  |>ersonncl  can  result  In  a  significant 
system  cost  advantage. 
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AbjLtx&at 

This  paper  describes  a  medium  sized 
Ada  development  activity.  The 
National  Training  Center  (NTC)  move 
and  upgrade  project  involved  the  movo 
of  the  Core  Instrumentation  System 
(CIS)  at  Ft.  Irwin,  California,  to  a 
new  facility.  The  project  required  a 
redesign  of  the  software  and  the  re¬ 
hosting  of  the  system  on  upgraded 
hardwaro.  The  new  architecture  was 
designed  to  handle  near-real-time 
data  rates,  digital  map  graphics, 
distributed  functionality,  unit  and 
player  symbology,  and  the  recording 
and  display  of  solectcd  statistical 
measures. 


latxadusllga 

The  National  Training  Center  (NTC), 
located  at  Fort  Irwin,  California,  is 
a  training  facility  which  provides 
mechanized  and  armor  battalions  an 
environment  for  developing  basic 
combat  skills.  U.S.  Army  units 
participate  in  two  week  exorcises  in 
which  thoy  engage  an  opposition  force 
trained  in  Warsaw  Pact  tactics.  Tho 
exorcises  aru  field  instrumented  and 
data  from  the  various  battles  is 
monitored  and  recorded  for  analysis 
and  playback.  The  incoming  data  rate 
is  10K  bytes  per  second. 

The  NTC  Instrumentation  System  (NTC- 
IS)  provides  the  means  to  collect, 
process,  analyze  and  display 
performance  data.  Major  NTC-IS 
functionality  includos  the  control 
and  monitoring  of  field  exercises, 
recording  and  replay  of  field  data, 
control  of  a  defensive  live  fire 
range,  presentation  of  statistical 
reports  in  support  of  performance 


measures,  and  the  preparation  and 
presentation  of  After  Action  Reviews 
(AAR). 

The  enhanced  system  required  the  use 
of  Ada  as  the  high-level  language. 
Tho  new  workstations  wero  to  provide 
a  windowing  capability  and  the  system 
was  to  be  composed  of  off-the-shelf 
components. 

The  upgraded  system  also  required  the 
development  of  nuclear  and  chemical 
casualty  prediction  models  for 
enhanced  indirect  fire  simulation. 


gxoJact.DQasrlg.tlga 

Current  System  The  current  system  is 
about  six  years  old.  It  is  based 
upon  a  distributed  architecture  and 
is  composed  of  four  Vax  ll/780s  which 
are  quad-ported  to  four  megabytes  of 
shared  memory.  Two  of  the  machines 
process  and  archive  incoming  data, 
while  two  are  file  servers  which 
respond  to  requests  for  data  at  the 
workstations.  Each  workstation  is 
made  up  of  an  LSI  11/23  processor,  a 
deAnza  graphics  monitor  and  a  Hitachi 
tablet  for  command  input.  The 
software  includes  about  130,000 
source  lines  of  Fortran  and  67,000 
lines  of  a  special  menu  description 
languages. 

Enhanced  System  The  enhanced  system 
was  hosted  or.  Sun  Microsystems 
hardware.  There  are  two  compute 
servers  and  two  file  servers.  The 
servers  are  Sun  3/280s  and  are 
attached  to  two  local  area  nets. 
Thirty  two  Sun  3/110  workstations  are 
served  by  the  file  servers.  All 
machines  use  Ethernet  protocol  for 
communication. 
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A  commercial  database  management 
system  was  used  to  load,  update  and 
maintain  the  statistical  data. 

The  new  system  carried  an  Ada 
software  requirement.  The  project 
was  relatively  short  fused,  with  a 
turn-on  to  delivery  period  of  about 
27  months.  The  software  architecture 
required  the  development  of  50 
computer  software  components  (CSCa). 
At  the  time  of  this  writing,  the 
project  was  30  days  away  from  its 
initial  operating  capability  (IOC). 


SoX.t,Ht£a..D.fly.filgancat-ABBi:gagb 

Considerations  Several  factors  led 
to  the  determination  of  a  suitable 
software  development  approach.  These 
factors  included 

-  the  background  of  the  staff, 

-  the  relatively  short  development 
time, 

-  the  existence  of  a  functional 
baseline  system  in  C  and 

-  the  target  hardware  chosen  for 
the  upgrade  system. 

The  staff  was  primarily  composed  of 
experienced  C  language  programmers 
with  a  strong  background  in  the 
techniques  of  structured  design. 
Several  senior  staff  members  were 
strongly  Ada  literate.  The  staff 
profile  was  rounded  out  with  entry 
level  personnel  having  some 
university  Ada  experience. 

The  target  hardware  system  was 
composed  of  workstations  which  were 
Ethernetted  together  and  which 
supported  the  development  of 
decoupled  modular  processes  which 
communicated  with  each  other  on 
several  different  functional  types  of 
workstations. 

The  Approach  The  structured  analysis 
and  design  techniques  as  described  by 
DeMarco* ,  Yourdon  and  Constantine* 
with  some  modification,  were  used  to 
develop  and  document  the  system 
design.  A  commercial  automated 

design  tools  from  Cadre  Technologies 
were  used  to  maintain  the  design. 
Ada  PDL  was  used  to  describe  the 


detailed  design.  The  Ada  PDL  was  not 
intended  to  ‘oa  restrictive.  It 
provided  a  means  of  capturing  the 
design  in  a  form  which  can  be 
processed  by  machine,  and  could  be 
transformed  into  Ada  code.  A  PDL 
unique  package  was  developed  to 
support  the  definition  of  functions 
not  yet  generated,  but  which  had  been 
identified  in  the  design  phase. 

A  prototype  system  written  in  C 
existed  prior  to  the  development  of 
the  upgraded  system  in  Ada.  Several 
of  the  CSCs  in  a  baseline  system  were 
identified  as  candidates  for 
translation  from  C  to  Ada.  A  tool 
developed  to  convert  the  C  source  to 
Ada.  The  Ada  was  then  massaged  by 
the  original  C  programmer  to  perform 
the  same  function  as  in  the  baseline 
system. 

Appropriate  coding  standards  and 
conventions  were  developed  and 
documented.  As  code  was  produced,  a 
software  quality  assurance  team 
insured  adherence  to  the  coding 
standards  document. 

The  Ada  development  environment  was 
provided  by  the  Verdix  Ada 
Development  System.  An  in-house 
compiler  queuing  system  was  developed 
which  kept  the  Ada  compilers  busy, 
but  not  overloaded. 

A  commercial  graphics  package  was 
solected  for  use  with  the 
workstations.  The  necessary 
graphics  libraries  were  developed  in 
the  Postscript  language.  Menu 
description  files,  also  in 
Postscript,  were  prepared  by  using  a 
proprietary  menu  layout  tool. 

Problems  Several  problems  arose 
which  had  major  impact  on  the 
software  development  process.  Of 
these,  the  Ada  development 
environment  and  staff  training  were 
the  most  serious. 

Ada  training  was  accomplished  through 
the  use  of  an  OJT  approach  combined 
with  a  series  of  Ada  round  table 
discussions  with  the  technical  staff. 
Programmers  whose  C  code  was 
translated  into  Ada,  learned  the  Ada 
syntax  while  massaging  the  translated 
source  into  a  form  which  compiled  and 
executed  correctly.  Designers  not 
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familiar  with  Ada,  learned  the  syntax 
when  exposed  to  Ada  PDL.  The  most 
Ada  literate  of  the  staff  were 
identified  as  resources  to  help  the 
Inexperienced  staff  members  with 
problem  resolution.  The  staff  was 
provided  with  reference  books  by 
Booeh1 ,  Olsen* ,  and  Barnes^ . 

The  most  significant  obstacle  to  be 
surmounted  was  the  Inadequacy  of  tho 
Ada  development  environment.  While 
the  resources  required  for  tho 
development  of  Ada  were  thought  to  be 
understood  prior  to  initial  coding, 
the  reality  of  the  situation  became 
clear  during  the  design  phase.  As 
more  Ada  PDL  was  generated  and 
compiled,  the  shortage  of  the 
secondary  storage  along  with  the 
foiling  of  the  compiler  to  keep  up 
with  the  demands  bolng  made  upon  it, 
quickly  outweighed  tho  problems  with 
the  language  itself.  Tho  compiler 
bottle-neck  was  partially  relieved  by 
the  purchase  of  two  additional 
compilers  and  the  development  of  an 
in-house  Ada  queuing  system  to  keep 
the  iempllers  busy,  but  not 
overloaded.  The  technical  staff, 
which  was  used  to  the  rapid  edlt- 
code-link-executa  loop  of  tho  C 
environment,  was  alow  to  adjust  to 
the  lengthy  Ada  compiler  turnaround 
time. 


Suaamrr  and.Cgnglualaaa 

Summary  Project  results  can  be 
summarised  with  several  measures. 
The  design  offort  produced  about  5200 
pages  of  dotailed  design 
documentation  at  a  cost  of  6250  man 
days  (md).  Source  linos  of  code 
(SLOC)  give  a  feeling  for  staff 
productivity  and  project  sise.  The 
source  linos  listed  below  represent 
non—omment  lines  of  Ada,  C,  and 
Postscript  (PS). 

SLOC  Ada  210,000 

SLOC  C  16,000 

PS  library  31,000 

PS  menu  173,000 

Total  software  development  man-days 
from  design  through  integration  is 
projected  to  be  17,544md.  Wot 
counting  the  auto-generated  menu 
description  code,  the  Ada,  C,  and 
Postscript  SLOC  were  produced  at  a 


rate  of  approximately  i5  lines  per 
programmer  day. 

The  error  detection  rate  gives  an 
idea  of  the  reliability  of  the  HTC 
software  system.  At  the  time  of  this 
writing,  the  error  detection  rate  is 
approximately  one  medium  or  highly 
critical  error  per  day.  A  more 
complote  analysis  of  reliability  will 
bo  made  at  the  completion  of  the 
integration  phase. 

Conclusion^  The  above  project 
description  and  results  lead  to 
several  conclusions  about  real-world 
Ada  development: 

-  A  significant  Ada  development 
project  can  be  successfully 
designed  and  Implemented  by  a 
relatively  Inexperienced  staff, 

-  the  Ada  development  environment 
must  improve  to  provide  more 
competition  for  established 
development  languages  like  C, 

-  structured  design  techniques 
will  produce  a  workable  design 
for  some  Ada  implementations, 

-  Ada  training  can  be  accomplished 
without  the  use  of  costly  and 
time  consuming  commercial  Ada 
training  programs. 
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Abstract 


Usa  of  Ada  doas  not  assura  software 
quality.  An  affactiva  software  quality 
assurance  plan  regains  a  necessity  for 
producing  quality  software.  Such  a  plan 
for  developing  Ada  software  using  DOD- 
2167A  is  described.  Experience  shows 
that  this  methodology  is  effective  in 
detecting  Misuse  of  Ada  as  well  as 
finding  certain  design  defects  early  in 
the  software  life  cycle. 


Introduction 


This  paper  describes  our  experience  with 
quality  assurance  work  in  the  design 
phase  of  an  Ada  software  devclopnenfc 
effort  using  the  D0D-2167A  Methodology 
(1]  at  the  Jet  Propulsion  Laboratory  at 
Pasadena.  The  design  Methodology  itself 
is  described  in  a  separate  paper  (2). 


Ada  end  Software  Quality 


Why  do  we  need  to  worry  about  software 
quality  when  coding  with  Ada?  Doesn't 
software  quality  come  automatically  with 
Ada?  certainly,  Ada  has  facilities  that 
encourage  production  of  quality  software, 
however,  like  all  tools,  Ada  can  be 
misused.  Use  of  Ada  alone  does  not 
assure  software  quality.  An  effective 
quality  assurance  plan  is  as  necessary  as 
ever  for  achieving  good  software  quality. 


Ihg-IngBQStlon-ilrgcggg 


The  cornerstone  of  the  software  quality 
assurance  plan  used  in  this  project  was  a 
review  process  that  uses  the  Fagan's 
inspection  method  [3].  The  inspection 
process  is  shown  in  figure  1. 

Defect  finding  is  accomplished  in  highly 
structured  meetings  by  a  t*ara  of 


John  Kelly 

Jot  Propulsion  Laboratory 
California  Institute  of  Technology 
Pasadena,  California 

Inspectors.  In  order  to  help  create  an 
ego-less  environment,  managerr  do  not 
participate  in  the  inspections.  At  JPL, 
the  detailed  defect  descriptions  were  not 
regularly  reported  to  the  manageMent; 
they  were  provided  with  a  statistical 
summary  report  at  the  conclusion  of  the 
process. 


Ihi.QualitY-AaRtttaDCR-JlM 


One  major  objective  of  the  quality 
assurance  plan  was  early  detection  and 
removal  of  defects.  With  this  focus, 
four  series  of  inspections  were  devised; 
two  during  the  preliminary  design  and  two 
for  the  detailed  design  phase. 

The  first  inspections  were  held  as  soon 
as  the  system  (CSC!)  functions  were 
allocated  to  the  Top-Level  Computer 
Software  Components  (TLCSCs) .  These 
Inspections  were  independent  of  Ada  and 
concentrated  on  high-level  issues  such  as 
completeness  of  the  top-level  design, 
traceability  to  the  requirements  and 
quality  related  factors  such  as  coupling 
and  cohesion  of  the  TLCSCs. 

The  second  series  of  inspections  were 
held  at  the  conclusion  of  the  next  lower 
level  of  decomposition.  This  is  the 
preliminary  design  phase,  according  to 
the  DOD-2167A  methodology,  when  the 
Computer  Software  Components  (CSC)  are 
produced. 

The  two  major  attributes  established 
during  the  preliminary  design  were  the 
top-level  concurrency  (i.e.  the  number  of 
tasks  in  each  CSC)  and  the  inter-CSC 
interfaces,  including  task  rendezvous. 

The  design  was  expressed  using  compiled 
package  specifications,  textual 
descriptions  and  entity  diagrams  giving 
pictorial  representations  of  the  top- 
level  control  and  data  flows.  The 
quality  factors  evaluated  at  this  stage 
were  uniformity  of  the  design  (clarity 
and  maintainability)  and  general 
provisions  for  exception  handling 
(reliability) .  The  package 
specifications  were  inspected  for 
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Figure  1:  The  Foroal  Inspection  Process 


information  hiding  (maintainability)  and 
use  of  strong  types  (reliability) .  other 
points  of  interest  were  the  concurrency 
and  rendezvous  provisions.  Theoe  were 
inspected  fro*  the  view  point  of 
necessity«  completeness  AhS  efficiency. 

The  preli*inary  design  review  was  held  at 
the  conclusion  of  the  rework  originating 
fro*  the  inspections. 

The  third  series  of  inspections  were  held 
very  ecrly  in  the  detailed  design,  that 
is  immediately  after  the  preliminary 
decomposition  of  the  CSC s  into  the 
Computer  Software  Units  (CSU) .  The 
primary  focus  of  tho  inspections  wax  to 
examine  tho  design  for  cohesion  and 
coupling  characteristics. 

The  fourth  and  final  series  of 
Inspections  were  hold  after  production  of 
compiled  Ad*  PDL  for  tho  package  and 
subprogram  bodies.  This  marks  the 
conclusion  of  the  detailed  design  phase. 
As  most  design  defects  had  been 
discovered  and  fixed  previously,  the 
focus  during  the  fourth  series  of 
inspections  was  on  quality  issues  seen  at 
the  lower  levels,  including  proper  use 
Ada  facilities.  Examples  of  the  Ada 
related  quality  factors  examined  during 
the  inspections  wore:  use  of  strong 
types,  proper  encapsulation  of 
exceptions,  information  hiding, 
rendezvous  performance,  non-use  of  non¬ 
portable  features,  use  of  the  Ada  generic 
facilities,  etc.  Clarity  and  readability 
of  the  POL  were  Also  examined.  The 
reworked  products  were  submitted  for  the 
D0D-2167A  critical  design  review. 

Lessons  Learned 


The  lessons  learned  are  presented  in  two 
parts:  the  first  part  addresses  the 
issues  related  to  Ada.  The  second  part 
deals  with  the  use  of  inspections  for 
quality  assurance. 

Improving  Software  Quality  With. Ada 

Our  experience  at  JPL,  the  California 
State  University  and  elsewhere  indicates 
that  classroom  training  alone  does  not 
result  in  programmers  writing  quality  Ada 
code.  Currently,  many  people  are  first 
time  users  of  Ada  and  need  guidance  on 
proper  use  of  the  language's  rich 
facilities.  To  some,  Ada  represents  what 
can  be  best  described  as  a  culture  shock 
..  "Why  isn't  it  enough  to  produce  a 
program  that  works"?  For  these  reasons, 
failure  to  use  some  of  Ada's  powerful 
features  for  improving  software  quality, 
is  a  major  problem.  It  is  not  uncommon 
to  discover  Ada  code  where  there  is  a  C 
or  assembler  program  trying  to  get  out! 

We  found  that  most  problems  with  non-use 


or  misuse  arise  in  the  areas  of  exception 
handling,  information  hiding,  use  of 
strong  types,  and  generic  facilities. 

Use  of  Ada  style  guides  provide  a  partial 
solution  to  this  problem.  However,  the 
real  solution  lies  in  formal  reviews;  our 
experience  shows  that  these  can  be  very 
effective  in  improving  software  quality 
by  weeding  out  poor  or  questionable 
coding  practices.  A  quality  assurance 
plan  basea  on  reviews  has  the  additional 
benefit  of  providing  on-the-job  training 
for  software  personnel  new  to  Ada. 

iJCEflYing.SgttMta-QuaUty-WiOi 
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The  distribution  of  defects  during 
preliminary  and  detailed  design  phases 
are  shown  in  figures  2  and  3 
respectively.  These  results  were 
gathered  from  inspections  on  a  total  of 
S3  different  CSUs.  Our  results  indicate 
that  during  tho  design  phase,  the  process 
is  most  effective  in  discovering  defects 
in  the  areas  of  clarity,  correctness, 
completeness  and  internal  consistency. 

The  composition  of  the  Inspection  team  is 
crucial  to  its  effectiveness.  A  good 
team  consists  of  engineers  specializing 
in  the  various  different  areas  of 
software  development.  The  inspectors 
must  be  "insiders",  collectively 
possessing  detailed  knowledge  of  the 
system  being  built.  The  team  has  to  be 
drawn  from  people  working  in  the  same 
project  but  in  other  areas.  The 
inspection  process  demands  a  good  deal  of 
the  engineer's  time.  As  delivery 
deadlines  approach,  inspectors  can 
become  a  very  scarce  commodity.  It  is 
vital  therefore  that  the  manpower 
requirements  for  inspections  are  factored 
into  the  project  resource  plans. 

In  this  project  a  typical  inspection  team 
consisted  of  the  author  together  with  a 
requirements  analyst,  taster,  user  of  the 
software  and  a  software  product  assurance 
engineer  who  acted  as  the  moderator.  On 
average,  it  took  0.5  work  hour  per  page 
to  complete  the  inspection  process  (this 
includes  all  time  expended  by  the 
moderator,  reader,  recorder,  author  and 
other  inspectors  for  all  seven  phases  of 
the  inspections) .  This  translates  to 
approximately  l  person  hour  to  fix  each 
defect.  In  both  cases  the  time  quoted 
covers  all  work  related  to  the 
inspection,  ie.  planning,  together  with 
finding  defects,  and  fixing  and  verifying 
correctness  of  the  solutions. 

It  is  important  to  establish  effective 
entrance  criteria  for  each  inspection. 
This  ensures  that  the  work  product  being 
inspected  has  reached  the  expected  level 
of  maturity  and  meets  the  minimum  quality 
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Software  Design  Document  (Preliminary  Design) 
Defect  Classification  Comparison 
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Figure  2:  Defect  Distribution  During  Frcll«ltvary  Design 


Software  Design  Document  (Detail  Design) 
Defect  Classification  Comparison 
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Figure  3:  Defect  Distribution  During  Detailed  Design 


standards,  Failure  to  do  this  results  in 
poorly  focused  Inspections  which  consume 
excessive  amounts  o£  tine.  This  is 
particularly  important  when  inspections 
ere  tied  to  project  milestones  and  when 
now  methodologies  and  languages  ore 
Involved. 


Our  overall  experience  is  that  an 
inrpeetion  based  quality  assurance  plan 
can  be  very  effective  in  early  detection 
of  design  and  coding  defects, 
considering  that  there  is  almost  an  order 
of  magnitude  escalation  in  the  relative 
cost  to  fix  errors  between  the  design  and 
testing  phases,  the  policy  of  early 
defect  removal  must  pay  handsome 
dividends  for  the  additional  investment 
in  effort  (4). 
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Aftsmcr 

Addressing  the  software  needs  of  large 
complex  eystoc*  first,  prior  to  selection  of 
t)»  hardwire  exponents  of  a  systeo,  b»  been 
a  goal  for  over  a  decade  and  a  half.  71w 
software  first  approach  require*  major 
revisions  to  current  systw  devdepront 
practices.  Elements  of  the  software  first 
approach  are  still  beyond  our  technical  grasp. 
Jfcwevcr,  the  significance  of  software  first  is 
that  it  provides  the  baseline  Into  which 
dements  of  system  devdopnent  should  fit. 
This  paper  provides  an  overview  of  software 
first  and  discusses  three  decent*  of  this 
approach  with  respect  to  current  capabilities. 
These  three  element*  are  requirements 
definition,  uses  of  prototyping,  and 
developpent  of  portable  software. 


nmooucnccJ 

[y  the  early  1970s  it  had  been  determined 
that  software  had  become  "the  tall  pole  in  the 
tent."  The  Air  Korea  budget  for  fiscal  year 
1972  indicated  that  between  SI  billion  and 
51. 5  billion  was  spent  on  software, 
approximately  three  tirns  the  cost  of  hard-are 
for  the  sane  period  JBOSf73).  Not  only  was 
software  costing  more  than  the  hardware 
exponent  of  a  system,  but  it  was  also 
believed  to  be  acre  responsible  for  schedule 
slippages,  cost  overruns,  operational 
penalties  and  performance  penalties,  as  well 
as  for  cocplex  embedded  problems  that  surfaced 
after  system  fielding.  Doth  the  concept  of 
software  first  and  a  software  first 
development  machine  wei-o  p.^poeed  in  the  early 
1970s  (D32173). 

Refinements  to  the  theory  of  software 
first  have  born  proposed  and  arc  currently 
receiving  each  attention  from  programs  such  as 
the  CoD's  STARS  (Software  Technology  for 
Adaptable,  Reliable  Systems)  program.  Ttx> 
commonality  of  these  approaches  is  the  concept 
of  developing  the  software  exponent  of  a 
system,  then  selecting  the  hardware  to  rapport 
the  system. 


The  major  benefit*  to  devdtping  the 
software  for  a  system  prior  to  hardware 
selection  include  the  development  of  software 
that  will  be  sore  aeJntairable,  since  all 
design  decisions  will  be  based  on  what  is  best 
for  the  software;  the  selection  of  hardware 
after  the  software  has  been  developed,  which 
enables  a  wiser  choice  circa  sore  is  town 
about  the  system,  as  wall  as  permitting  the 
Jwudware  to  mature  an  additional  few  year* 
while  the  software  is  being  developed;  and  the 
better  management  of  cvoluticmty  requirements 
since  no  hardware  ha*  been  selected  and 
therefore  locked  into  the  system. 

It  should  bo  noted  that  severe!  of  the 
exponents  of  software  first  do  not  require  a 
strict  adherenoo  to  the  software  first 
philosophy.  Portions  of  thin  methodology 
will,  therefore,  be  usable  with  a  core 
traditional  development  approach;  other 
portions  will  be  specifically  linked  to  this 
methodology.  The  significance  of  the  software 
first  approach  is  that  it  provides  a  goal 
toward  which  various  elements  of  software 
development  should  evolve.  For  cxasple,  work 
on  new  testing  strategies  should  address  the 
needs  of  testing  portable  software  while 
decreasing  the  sensitivity  of  the  software  and 
testing  process  to  the  target  machine,  By 
maintaining  consistency  with  a  cowtx;  goal, 
these  s  olving  strategies  will  be  supportive 
of  a  larger  methodology  and  bn  mutually 
oorpatible.  Another  advantage  of  this  is  that 
Rich  of  the  benefit  of  software  first  can  be 
realized  without  waiting  for  all  the 
technology  noodot}  to  fully  implement  the 
model, 

7'i  literally  implement  the  recently 
proposed  model  of  software  first  (BR0068)  ray 
bo  beyond  the  grasp  of  today's  technology  in 
sera  key  areas.  Several  dements  of  that 
redd,  however,  can  be  supported  with  existing 
technology. 

The  balance  of  this  paper  presents  an 
overview  of  software  first,  details  the  use  of 
requirements  definition,  prototyping,  and 
portable  software  within  the  software  first 
concept,  and  presents  conclusions. 


Support  for  this  research  was  provided  through  RADC  contract  number  F30602- 
86-C-011J  with  funds  provided  by  CSCGM  Oenter  for  Software  Engineering. 
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OVERVIEW  or  SOFTWARE  FIRST 

Th«  traditional  method  of  system 
davelopxnt  is  to  choose  the  hardware  for  the 
systen,  fit  the  aoftuere  to  the  systee,  then 
add  hardware  components,  and  both  add  ard 
alter  software  ccwpcnents  to  make  the  system 
work,  fly  the  tine  the  system  is  fielded,  the 
hardware  is  several  years  old  and  no  longer 
state  of  the  art.  The  software  design  has 
been  altered  to  fit  the  hardware  of  choice, 
often  incorporating  hardware  characteristics 
into  the  software  design,  and  hut  there/"  « 
become  both  rachine-depadent  and  diffiaC '  wo 
maintain.  And,  the  schedule  has  slipped 
because  of  this.  The  negative  effects  of  this 
approach  became  even  rvore  pronounced  during 
the  maintenance  phase  of  the  life  cycle.  In 
addition,  when  the  system  development  is 
completed,  often  it  no  longer  newts  the  roods 
of  the  user,  principally  due  to  the  lack  of 
interaction  with  the  user  during  the 
development  process.  As  originally  conceived, 
the  goal  of  software  first  was,  and  still  is, 
to  reduce  total  life  cycle  costs.  He  felt 
this  could  be  done  by  increasing  user 
involvement  and  postponing  ti»  selection  of 
the  hardware.  This  seewsd  odey  enough  to 
achieve,  in  the  ideal  case,  end  resulted  in 
the  nodal  shown  in  FXOURF  1.  Hu  recognira 
that  software  development  is  not  easy  and  that 
departures  from  the  ideal  model  arc  rtaoded  if 
wa  are  to  have  a  realistic  approach.  Wo  also 
realize  that  the  closer  to  the  ideal  model  w<a 
stay,  the  easier  to  understand  and  implement 
the  approach.  The  result  is  a  pL\Mi  which 
allows  departures  from  the  ideal  model  only 
when  necessary  and  views  these  departures  as 
ones  which  should  eventually  bo  solved  by 
future  technology.  In  order  to  reduce 
implementation  time,  we  propose  to  use  or 
adopt  as  much  of  existing  technology 
(methods, tools)  as  possible,  and  to  structure 
the  implementation  in  nodular  fashion,  to 
allow  pieces  of  it  to  be  implemented  and  used 
as  sock  as  possible.  Throe  examples  of  this 
modular  approach  am  discussed  in  depth  later 
in  this  paper. 


As  vc  proceeded  with  cur  definition  and 
analysis,  wu  discovered  that  software  first 
provided  solutions  to  many  problems 
encountered  in  today's  develcpaenta.  and 
provided  the  Mans  for  implementing  ideas, 
which  would  stmmline  the  over  all  process 
further.  Tire  end  result  is  the  node!  shown  in 
FIGURE  2.  A  major  benefit  of  software  first 
is  that  it  forces  the  system  to  be  viewed  as  a 
system  as  opposed  to  several  systems 
(hardware,  software,  logistic)  as  wo  do  today, 
and  the  "systems’1  to  become  views  of  the  samn 
system.  It  also  allows  requirements  anl 
design  decisions  to  be  made  without 
unnecessary  constraints.  To  take  advantage  of 
this  benefit,  the  aoftware  first  approach 
places  heavy  emphasis  on  requirements 
definition. 

Tito  purpose  of  requirements  definition  is 
to  assure  that  the  user  and  the  developer,  aid 
any  other  key  people  involved  in  the 
development,  mutually  understand  the 
requirements.  Since  English  is  an  asbiguous 
language,  requirements  written  in  English  art 
apt  to  be  ambiguous;  therefore,  it  is 
necessary  to  iterate  the  requirements  to 
assure  that  they  urs  mutually  understood. 
Since  complete  mutual  understanding  and 
agreement  is  a  naive  goal,  the  user  and 
developer  rust  continue  to  interact  during  the 
development  to  bring  to  the  surface 
differences  in  interpretation  as  early  as  they 
are  recognized. 

Other  intents  of  requirements  definition 
in  software  first  are  to  ensure  that  the  user 
is  asking  for  what  ho  noeds,  that  the  user  and 
developer  understand  oach  other,  and  that  the 
requirements  ere  feasible  with  today's 
technology.  An  underlying  there  of  the 
approach’  used  hare  is  tl»t  the  requirements 
focus  on  what  is  to  bo  done,  not  how  it  is  to 
be  done.  Only  after  the  requirements  have 
been  established  are  they  partitioned  into 
software  and  hardware  requirements.  This  will 
facilitate  maintaining  a  focus  on  the 
requirements  and  avoid  performing  premature 
system  design. 


FIGURE  1.  THE  IDEAL  MDOEL  FOR  SOFTWARE  FIRST 
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Th*  Ma  language  plays  a  toy  rola  in 
facilitating  the  requirarants  definition 
prccc**,  particularly  the  Ada  pedcage.  The 
package  rakes  two  significant  contributions: 
first,  a  package  ray  define  a  capability  that 
will  not  be  implemented  in  the  initial 
delivery  of  the  systra;  and  second,  a  package 
my  ultimately  be  developed  in  either  hardware 
or  software. 

The  advantage  of  putting  specific 
capabilities  into  packages  is  that  the  pedcage 
is  built  into  the  design  as  part,  of  the 
initial  design  process,  even  if  the  pedcage  is 
not  implemented  as  part  of  thn  initial 
delivery.  Same  accomodations  sort  be  made, 
obviously,  to  ensure  that  an  uniaplcmnted 
package  is  not  called  by  the  isploaontod 
system  Given  the  nature  of  the  Ada  program 
design  languages,  the  interdependencies  of 
packages  are  quite  easily  observed  and 
controlled.  The  second  contribution  directly 
supports  the  central  them  of  software  first, 
postponing  the  selection  of  hardware  as  long 
as  possible. 

Once  system  requirements  have  boon 
developed  and  are  being  partitioned  into 
hardware  and  software,  all  fisictions  are  to  be 
implemented  in  software  unices  hardware  is 
clearly  superior  for  implementing  the 
function.  The  rationale  for  this  is  to  avoid 
the  nooessity  of  hardware  upgrades,  and  the 
resulting  impact  on  the  system.  Changing  the 
hardware  which  implements  specific  system 
functions  causes  perturbations  in  the  system 
design;  this  can  possibly  be  avoided  by 
implementing  tivoee  functions  in  software. 

In  software  first,  the  development  host 
plays  a  critical  role  in  the  success  of  tins 
project,  since  all  the  development,  training, 
and  maintenance  will  be  done  on  it.  While 
this  increases  the  importance  of  choosing  the 
host,  it  alleviates  many  problems  which  result 
from  the  use  of  multiple  hosts  (wo  consider 
the  target  a  type  of  host) ,  during  the 
remainder  of  a  system's  life.  An  example  is  a 
problem  encountered  with  many  complex  systems 
that  the  intendod  operator  is  unable  to 
operate.  This  occurs  when  the  developed  ran- 
rachine  interface  is  incomprehensible  to  the 
human  »ho  is  expected  to  operate  the  system. 
The  traditional  adjustment  is  to  build  another 
layer  onto  the  existing  run -machine  interface 
to  enhance  the  system's  ease  of  operation. 
This  additional  layer  has  several  negative 
effects.  It  degrades  performance,  it  alters 
the  software  architecture,  it  increases  cost 
and  delays  schedule,  and  generally  aggravates 
a  bad  situation.  Using  the  host,  the  man- 
machine  interface  can  be  implnented  and 
tested  using  all  the  capabilities  available  on 
the  host.  Sinoe  it  is  being  developed 
integrally  with  the  rest  of  the  software, 
implications  of  changes  to  the  interfaces  can 
be  gauged  accurately.  This  allows  early 
visibility  into  potential  problem  areas  and 


allows  the  urar  and  developer  to  rationally 
select  the  best  of  the  available  alternatives, 
instead  of  being  forced  into  raking  a  decision 
under  the  pressures  of  a  delayed,  overrun 
delivery. 

Software  first  incorporates  early 
training  for  multiple  reasons.  First,  early 
training  will  identify  any  discrepancies 
between  the  skills  necessary  to  operate  the 
system  and  the  abilities  of  the  anticipated 
operators.  Also,  try  utilizing  a  trainer, 
another  perspective  on  the  functionality  of 
the  system  will  be  obtained  which  ray  further 
identify  differences  between  whet  the  user 
needs  and  what  the  developer  is  building. 
Further,  with  training  started  early  in  the 
life  cycle,  trained  operators  will  be 
available  when  the  system  is  fielded.  These 
changes  to  the  traditional  development  cycle 
mandate  other  changes. 

First,  in  order  to  begin  training  early, 
a  prototype  of  the  man-mchina  interface  must 
exist  early.  This  is  required  to  define 
exactly  the  set  of  functions  that  the  operator 
of  the  system  must  perform  and  to  detail  the 
information  presented  to  the  operator  by  the 
system.  Zf  this  early  information  indicates 
that  the  man-machine  interface  is  inconsistent 
with  the  capabilities  of  the  operator,  then 
changes  can  be  incorporated  into  the  system. 

Training  on  the  host  provides  other 
advantages.  It  provides  the  opportunity  to 
initiate  training  before  the  system  has  been 
flcldod.  This  presents  tho  opportunity  to 
have  the  operators  trained  prior  to  system 
fielding.  Also,  since  maintenance  is  also 
performed  on  the  host,  the  updated  system  can 
be  introduced  to  the  operators  prior  to  being 
flcldod.  This  permits  the  opportunity  to 
determine  the  effect  on  the  operator  of  any 
system  upgrades  before  those  upgrades  are 
reloasod.  Finally,  the  host  envirement  is 
much  more  robust  than  the  fielded  system. 
Tools  that  are  used  for  development  can  also 
be  used  to  support  the  training  process. 

In  addition  to  the  training  advantages 
that  a  prototype  of  the  man-machine  interface 
provides,  the  prototype  enables  the  user  to 
get  yet  another  view  of  the  developer's 
perception  of  the  system.  Typically,  a 
system's  functionality  is  viewed  fnxj  the 
global  perspective,  which  tends  to  be 
abstract.  This  global  perspective  usually  is 
expressed  in  terms  of  the  effect  of  the  system 
on  its  envirement.  By  defining  the  avr- 
rachine  interface,  the  user  and  developer  can 
observe  exactly  how  the  system  will  implement 
the  desired  effect.  This  more  concrete  view 
of  how  the  system  will  operate  increases  the 
probability  that  the  user  and  developer  truly 
understand  each  other. 

The  system  prototype  effort  will  focus  on 
the  requirements  that  are  considered  "high 
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risk,"  and  ths  connection  between  theca 
••looted  requirements  and  any  hardware 
necessary  to  implement  then  will  be 
continuously  explored.  The  sore  general 
hardware  requirements  of  the  evolving  software 
will  also  be  monitored  and  evaluated.  The 
software  first  approach  requires  the  software 
to  be  developed  before  the  hardware  is 
selected.  In  practice,  it  will  be  necessary 
to  estirote  the  system's  hardware  needs  early 
in  the  development  cycle,  and  assess  the 
feasibility  of  available  hardware  to  meet 
these  needs.  As  the  software  is  being 
developed,  the  retirements  for  the  hardware 
which  will  execute  the  software  will  become 
more  clear.  As  these  requirements  become 
clear,  the  feasibility  of  existing  hardware  to 
satisfy  the  requirements  will  be  assessed.  In 
this  way,  the  desires  of  the  software  world 
will  be  tempered  by  the  realities  of  the 
hardware  world. 

In  software  first,  the  software  is 
designed,  developed  and  implemented  on  the 
host  environment.  This  is  to  ensure  that  the 
software  portion  of  the  system  functions  as 
intended  on  the  host  environment  prior  to 
selection  of,  aid  retargeting  to,  the  target 
environment.  The  software  testing  takes  plaoe 
on  the  host  environment  as  part  of 
development,  and  again  later  as  part  of 
hardwar^/softwa^  integration.  Also,  all 
training  and  maintenance  are  to  be  performed 
on  the  host  envixermnt. 

The  portability  of  Ada  is  a  boy  factor  in 
the  integration  of  the  software  and  the  target 
hardware.  The  target  machine  is  chosen  based 
Upon  the  needs  of  the  software.  While 
operating  on  the  host,  the  memory  and  timing 
needs  of  the  software  are  evaluated.  Hard-are 
is  then  selected  that  can  meet  these  needs. 
The  hardware  that  is  enhedded  into  the  system 
to  perform  specific  system  functions  is  also 
chosen  at  this  time.  By  delaying  all  hardware 
selections  until  after  the  software  is 
developed,  the  most  current  hardware  can  be 
used  in  the  system. 

Curing  acceptance  testing  the  adequacy  of 
the  hardware  is  assessed.  If  the  initial 
hardware  does  not  satisfy  the  system 
requirements,  then  a  change  in  hardware  must 
be  made.  The  likelihood  of  the  hardware  being 
acceptable,  however,  is  very  high  as  the 
precise  needs  of  the  hardware  were  identified 
prior  to  selection. 

The  primary  significance  of  the  field  and 
support  phase  is  that  the  support  is  performed 
in  the  host  environaent.  Typically,  host 
environments  have  access  to  several 
sophisticated  software  development  tools. 
These  range  from  requirements  analysis  tools, 
to  design  tools,  to  documentation  generation 
tools,  to  testing  tools.  These  tools  are  net 
available  in  the  target  environment  where 
maintenance  is  typically  performed.  The 


benefits  of  using  the  host  for  maintenance  is 
twofold.  The  tools  available  on  the  host  make 
updating  the  software  easier,  and  the  total 
ispact  of  any  changes  to  the  software  is 
easier  to  assess  since  t)»  changes  are  being 
implemented  in  the  same  envirorsrunt  used  for 
develcprent.  When  a  suggested  change  to 
system  software  is  made,  the  impact  of  that 
change  on  the  other  system  software  is 
assessed  using  the  documentation.  The  change 
is  implemented  in  the  supportive  host 
environment,  instead  or  the  austere  target 
environment,  and  the  entire  si's  ten  is  retasted 
to  assure  that  changes  made  have  not  had  an 
undesirable  effect  on  the  system.  Of 
particular  interest  are  potential  efforts  on 
the  system's  ability  to  moot  timing 
requirements. 

Several  key  aspects  of  software  first  can 
be  implemented  within  today's  technology. 
These  include  enhanced  requirements 
definition,  use  of  prototyping  for  multiple 
purposes;,  and  developing  portable  software. 
These  facets  of  the  methodology  will  be 
discussed  in  detail  in  the  following  sections. 


FEOUrREHENIS  DEFINITION 

Criteria 

There  are  two  assumptions  on  which 
software  first  is  based: 

Software  is  flexible  and  can  be  altered; 

If  developed  correctly,  software  can 

outline  several  generations  of  hardware. 

Each  of  these  assumptions  must  bo  qualified. 
Although  software  is  flexible,  the  less  it  is 
forced  to  flex  the  more  likely  the  software 
dovolopnont  and  maintenance  will  be 
successful.  To  develop  software  oorxectly 
necessitates  understanding  user  retirements 
and  anticipating  future  requirements. 
Therefore,  to  both  reduoe  the  need  for 
altering  software  and  to  increase  the 
likelihood  of  long  life  necessitates  doing 
more  thorough  requirements  analysis. 

This  section  of  this  paper  outlines  the 
criteria  for  reqiireracnts  analysis  relative  to 
supporting  software  first;  the  next  section 
discusses  the  ability  of  current  tools  to 
satisfy  these  criteria. 

Currently,  requirements  are  typically 
written  in  a  natural  language.  These 
documents  vary  in  length,  but  are  usually  long 
enough  to  prohibit  a  detailed  understanding  of 
the  system  requirements  by  anyone  other  than 
the  author  of  the  document.  This  inability  to 
understand  requirements  documents  is  due  to 
the  astoiguity  and  lack  of  specificity  of 
natural  language,  and  the  inability  to  check 
for  consistency  or  to  maintain  the  document 
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due  to  lack  of  tools.  In  spite  of  thane 
shortcomings,  requirements  continue  to  be 
written  in  natural  language  due,  in  part,  to 
the  fact  that  reading  natural  documents 
requites  no  specific  training.  Because  of 
these  shortocnims,  theta  is  Bovwmnt  within 
the  software  engineering  ocenunity  toward  mote 
formalism  in  requirements  documnts. 

Id  introduce  formal  is*  into  requirements 
documents  necessitates  a  representation 
scheme.  Canon  representation  schemes  include 
finite  state  machines,  program  design 
languages,  docision  trees,  and  Petri  Sets. 
The  advantages  of  this  introduction  of 
formalism  include  the  virtual  elimination  of 
ambiguity  and  the  existence  of  tools  to 
support  the  consistency  and  enhance  the 
Maintenance  of  the  requirements  docoacnt.  The 
disadvantage  to  the  introduction  of  formalism 
Into  requirements  documents  is  that  it 
necessitates  training  in  the  specific 

representation  scheme.  A  discussion  on 

specific  techniques  for  introducing  formalism 
into  requirements  documents  is  contained  in 
the  next  section. 

At  this  time,  no  single  technique  for 
improving  requirements  documents  is  dominant. 
Several  exist,  each  with  its  own  advantages 
and  disadvantages.  What  is  necessary  is  a  set 
of  criteria  to  evaluate  requirements 
techniques  for  a  particular  system 
development.  Throe  key  elements  in  the 

^"ation  criteria  are  the  user,  the 
oer,  and  the  application. 

sot  of  eight  criteria  for  evaluating  a 
fct  .qu-r  have  been  proposed  (DAVI88): 

When  the  technique  is  properly  Used,  the 
resulting  document  should  be  helpful  and 
understandable  to  non-oarputer-orienbod 
customers  and  users. 

When  the  techniques  is  properly  used,  the 
resulting  document  should  be  able  to 

serve  effectively  as  the  basis  for  design 
and  testing. 

The  todriique  should  provide  automated 
chocks  for  ambiguity,  inoonpleteness,  and 
inconsistency. 

The  technique  should  encourage  the 
requirements  writer  to  think  and  write  in 
terms  of  external  product  behavior,  not 
internal  product  oorpononts. 

The  technique  should  help  organize  the 
document. 

The  technique  should  provide  a  basis  for 
automated  prototype  generation. 

The  technique  should  provide  a  basis  for 
automated  system  test  generation. 


The  technique  should  be  suitable  to  the 
particular  application. 

There  are  additional  criteria  that  Bust  be 
added  to  this  set  to  specifically  support 
software  first: 

The  technique  should  support  iterative 
development  of  the  docunent. 

The  technique  should  support  stepwise 
refinement  of  the  document. 

The  technique  should  support  the 
identification  of  related  and 
interdependent  requirements  listed  in  the 
document. 

The  technique  should  support  the  concept 
that  the  nan,  or  operator,  is  part  of  the 
system. 

Some  elaboration  of  each  of  these 
criteria  follows. 

The  technique  Bust  produce  a  document 
that  is  understandable  to  non-ooeputwr- 
orientod  individuals  since  a  high  percentage 
of  system  users  is  non-conputer-oriented. 
Many  systems  produce  documents  using  a  formal 
representation  scheme.  Since  the  document 
rust  be  understood  by  users  who  are  non- 
conputer-oriented,  the  representation  scheme 
Bust  be  easily  understood.  Thn  need  for  some 
training  is  inevitable?  a  very  short  training 
session  rust  be  adequate  or  system  users  will 
not  accept  the  requirements  tedvuque. 

Once  the  requirements  document  is 
understood  by  both  user  aid  developer  it  Bust 
drive  both  the  system  design  and  the  testing 
process.  The  requirements  process  Bust  focus 
on  what  the  system  is  to  do  and  avoid 
addressing  how  the  system  is  to  do  it.  This 
line  becomes  blurred  if,  for  exasple,  the 
representation  scheme  is  a  program  design 
language.  This  need  to  be  the  basis  for  a 
design  Bust  not  beocme  an  excuse  for  allowing 
the  requirements  document  to  become  a  design 
document.  Therefore,  the  system  functionality 
Bust  be  evident  in  the  design  docuaent  without 
this  docuaent  constraining  the  design.  The 
statement  that  the  requirements  document 
should  serve  as  a  basis  for  design  Bust  be 
interpreted  to  mean  that  this  document  exposes 
the  functionality  of  the  system  to  the  design 
team,  not  that  it  defines  a  particular  design. 
The  support  for  testing  comes  frcm  the  ability 
to  easily  interpret  the  functionality  of  the 
system  into  test  cases.  Again,  the  test  cases 
are  not  to  be  enhedded  in  the  requirements 
docuaent,  but  rather  the  requirements  are  to 
be  stated  in  a  Manner  that  facilitates  the 
development  of  test  cases. 
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The  primary  shortcomings  of  using  natural 
language  for  a  requirements  document  are  the 
ambiguity  of  natural  language  and  the 
inability  to  formally  determine  properties 
such  as  completeness  and  consistency  of 
documents  written  in  natural  lanqaaga. 
Therefore,  the  primary  capabilities  for  a 
technique  other  than  natural  language  mst 
include  checks  for  asbiguity,  incompleteness, 
and  inconsistency.  Given  the  size  of  the 
requirements  documents  of  interest,  these 
checks  mst  be  automated. 

Underscoring  the  need  to  focus  on 
requirements  and  avoid  design  during 
requirements  analysis,  is  the  criteria  that 
the  technique  should  encourage  the 
requirements  writer  to  think  and  write  in 
terms  of  external  product  behavior.  This 
emphasis  focuses  the  requirements  process  on 
what  the  system  will  do  and  avoids  the  trap  of 
defining  how  the  system  will  da  it.  The 
requirements  writer  mst  also  consider  that 
the  system  operator  is  internal,  not  external, 
to  the  system. 

Requirements  are  frequently  generated  in 
a  disorganized  manner.  The  individuals 
involvod  in  determining  system  requirements 
may  generate  a  lengthy  list  of  complex 
requirements.  The  technique  must  aid  in 
structuring  this  list  into  a  ochcrent 
document.  Hare  specific  information  on 
organizing  the  requirements  document  is 
provided  with  the  criteria  developed  to 
specifically  support  software  first. 

Automated  prototype  generation  and 
automated  test  case  generation  are  two 
capabilities  that  are  gradually  boocmlng 
available  in  requirements  techniques.  These 
criteria  would  more  accurately  be  stated  as 
automated  support  for  generation  of  prototypes 
and  test  cases  than  automated  generation  per 
so.  The  benefit  of  a  formal  representative 
scheme  is  the  potential  to  automat-  the 
translation  of  acquirements  stated  using  the 
schema  into  a  prototype  or  test  cases.  The 
need  for  prototypes  during  requirements 
analysis,  as  stated  elsewhere  in  this  report, 
is  to  provide  additional  perspective  on  the 
requirements.  T«>e  need  for  test  case 
generation  is  to  assure  coverage  of  all 
requirements  by  the  testing  process. 

Several  of  the  existing  requirements 
techniques  were  developed  for  a  specific 
application  domain.  Sene  arc  applicable  to 
other  domains.  Part  of  the  evaluation 
criteria  of  requirements  techniques  for  a 
particular  system  is  establishing  the 
suitability  of  the  technique  for  the  specific 
application.  The  most  direct  measure  of  this 
suitability  would  be  to  establish  that  the 
technique  had  been  successfully  utilized  by 
the  user  and  the  developer  previously  on  a 
project  in  the  same  application  domain. 


The  last  four  criteria  were  added  to 
specifically  support  software  first.  The 
software  first  model  proposes  a  strong 
oomitnent  to  iterative  development  of  the 
rysten  requirements.  This  translates  into  the 
need  of  a  technique  that  supports  early  and 
frequent  charges  to  the  document.  Also 
necessary  are  version  control  and  archiving  of 
previous  versions  to  enable  the  reconstruction 
of  a  previous  iteration  of  the  document  if  an 
implemented  change  is  to  be  deleted.  The 
requirements  document  in  software  first  will 
evolve  and  this  evolution  must  be  supported  by 
the  technique  used  to  develop  the  document. 

Stepwise  refinement  is  related  to 
Iterative  development.  The  stepwise 
refinement  process  involves  taking  a 
requirement  and  refining  that  requirement  by 
adding  specificity  and  detail.  This  preoess 
does  not  change  requirements  but  rather 
details  the  existing  requirements.  Support  in 
tills  area  includes  tracing  the  evolved 
requirements,  assuring  that  the  refined 
requirements  cover  all  aspects  of  the  initial 
requirement,  and  identifying  redundant 
elements  in  the  set  of  refined  requirements. 

The  organization  and  structuring  of  the 
requirements  document  noted  earlier  has 
specific  implications  for  software  first. 
Related  requirements  would  include 
requirements  that  address  a  particular  high- 
level  function  or  capacity  of  the  system. 
Interdependent  requirements  have  correlation'll 
or  casual  links  between  them.  These  links 
must  be  identified  by  the  technique  and 
exposed,  on  request,  to  the  user. 

Software  first  supports  the  concept  that 
the  system  being  developed  includes  the  human 
with  when  the  system  will  bo  interacting.  The 
implications  of  this  concept  include  that 
requirements  relative  to  the  user  mist  bo 
included  in  the  requirements  document  and  that 
the  man  machine  interface  is  an  integral 
component  of  the  system,  not  an  after-the-fact 
appendage.  Assumptions  about  the  capabilities 
of  the  human  can  be  noted  easily  onoe  the 
requirements  relative  to  the  human  are  in  the 
requirements  document,  ftitamatod  support  for 
extracting  and  itemizing  these  requirements  is 
essential  in  deducing  the  capabilities  the 
human  is  assumod  to  have.  These  assumed 
capabilities  can  then  be  cocpored  and 
contrasted  to  the  anticipated  user 
requirements.  Discrepancies  can  then  be 
addressed  as  appropriate. 

Ttols 

Requirements  analysis  has  been  singled 
cut  as  a  key  process  in  software  first,  worthy 
of  new  and  better  techniques  for  defining 
requirements.  Therefore,  existing  cools  for 
requirements  analysis  have  toon  studied  for 
applicability. 
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Automated  tools  for  rsquirewnts  analysis 
say  ba  catagorizad  in  a  number  of  different 
ways.  Sena  tools  hava  been  designed  to 
automate  the  generation  and  maintenance  of 
what  was  originally  a  manual  method  and  these 
tools  typically  make  use  of  a  graphical 
notation  for  analysis.  This  class  of  tools 
produces  diagrams,  aids  in  problem 
partitioning,  maintains  a  hierarchy  of 
information  about  the  system,  and  applies 
heuristics  to  unoovar  problems  with  the 
specification.  Mora  importantly,  such  tools 
enable  the  analyst  to  ipdate  information  and 
track  the  connections  between  new  and  existing 
representations  of  the  system.  Ftor  exasple,  a 
number  of  CASE  (Caaput ar  Aided  Software 
Engineering)  tools  enable  the  analyst  to 
generate  data  flow  diagrams  and  a  data 
dictionary  and  maintain  these  in  a  database 
that  can  be  analyzed  for  correctness, 
consistency,  and  oatpleteness.  In  fact,  the 
true  benefit  of  this,  and  of  most  autorated 
requirements  tools,  is  in  the  "intelligent 
processing"  that  the  tool  applies  to  the 
problem  specification. 

Another  class  of  automated  requirements 
analysis  tools  makes  use  of  a  spocial  notation 
(in  most  cases  this  is  a  requirements 
specification  language)  that  is  prooessod  in 
an  automated  manner.  Requirements  are 
described  with  a  specification  language  that 
carbines  keyword  indicators  with  a  nature.', 
language  narrative.  The  specification 
language  is  fod  to  a  processor  that  produces  a 
requirements  specification  and,  more 
importantly,  a  set  of  diagnostic  reports  about 
the  consistency  and  organic  cion  of  the 
specification. 

After  the  system-level  requirements  have 
been  defined  through  user-developer 
interaction  and  the  vse  of  requirements 
analysis  tools,  the  next  step  in  the  software 
first  approach  is  to  partition  the 
requirements  into  software  and  hardware 
requirements. 

Thanks  to  recent  strides  in 
microprocessor  technology  and  in  software 
engineering  (e.g.,  the  development  of  Ada), 
the  size  and  complexity  of  embedded  real-time 
systems  have  grown  explosively.  It  is  now 
practical  to  implement  many  functions  in 
software  that  earlier  would  have  been 
relegated  to  hardware.  This  flexibility  has 
led  to  the  software  first  bias  toward  software 
implementation  of  a  function  whenever 
possible.  Vihen  the  project  begins,  the 
designers  do  rot  know  the  functional  system 
division  between  the  hardware  and  the 
software.  Tools  that  supply  the  hierarchical 
functional  deoerposition  framework  can  be  used 
to  help  define  exactly  which  functions  should 
be  performed  in  hardware  and  which  in 
software. 


Several  of  the  tools  that  ixplmnent  the 
oonten  methods  for  requirements  definition  and 
requirements  analysis  have  recently  been 
evaluated  against  the  criteria  defined  in  the 
preceding  section  (DAVI88) :  output  that  is 
understandable  to  non-coeputer-oriented  users; 
output  that  forms  a  basis  for  design  and 
testing;  automated  checks  for  arbiguity, 
incompleteness,  and  inconsistency;  system  view 
is  in  terms  of  external  behavior;  output 
should  be  organized;  tool  should  support 
automated  generation  of  prototypes  and  test 
cases;  and  the  tool  should  support  the 
specific  application.  The  tools  are  based  on 
either  finite  state  machines,  decision  tables 
or  decision  trees,  program  design  language, 
structured  analysis,  or  Petri  nets. 

Finite  state  machines  appear  to  provide 
the  superior  representation  against  the  stated 
criteria,  with  the  only  major  drawback  being 
the  amount  of  training  to  understand  the  tools 
and  their  inputs  and  outputs.  Decision  tables 
or  decision  trees  are  most  appropriate  for 
decision-intensive  applications,  and  tools 
based  on  this  model  do  not  provide  for 
automated  checking  of  requirements  for 
ambiguity,  incompleteness,  or  inconsistency. 
Further,  these  tools  oo  not  provide  support 
for  prototype  cr  test  case  generation.  The 
strength  of  program  design  language  tools  is 
that  thoy  are  intuitive,  due  to  their 
similarity  to  natural  language;  the  weakness 
is  the  lack  of  formalism  necessary  to  assure 
well  structured  documents  to  drive  well 
structured  designs.  Static  analysis  can  be 
performed  to  detect  structural  errors,  but 
this  is  more  beneficial  in  the  design  phases 
than  in  requirements  definition.  Structured 
analysis  tools,  even  those  extendod  to  support 
roal-tina  applications,  are  more  appropriate 
for  systems  based  on  data  flow  and  data 
structure.  This  loads  to  a  data-flow  view  of 
the  system,  not  an  external  view.  Static 
structural  and  behavioral  analysis  can  be 
performed,  but  the  structure  is  data  driven. 
Petri  nets  are  strong  at  representing 
synchronous  behavior,  but  appear  to  be  hard  to 
master,  particularly  for  the  non-oceputer- 
oriented  user. 

Tools  based  on  the  finite  state  machine 
model  appear  to  be  the  most  supportive  of 
requirements  definition  process  detailed  in 
the  previous  section. 


PROTOTYPING 

The  proposed  approach  to  software  first 
relics  an  prototyping  to  accomplish  several 
goals.  These  include  requirements  definition, 
ccrrunication  between  user  and  developer, 
definition  of  the  non -machine  interface,  early 
availability  of  training  devioes,  and 
determining  feasibilities  of  parts  of  the 
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system.  This  •action  discusses  several 
aspects  of  prototyping  relative  to  software 
first. 

Motivation 

Requirements  are  difficult  to  state 
explicitly  and  ccrplctely  at  the  outset  of  a 
project.  The  user  nay  Know  the  need  but  bo 
unclear  about  the  details  of  the  solution. 
Users  and  developers  must  deal  with  inherent 
ccmunication  boundaries;  what  one  neans  to 
say  nay  not  be  what  the  other  hears.  Waiting 
until  later  in  the  project  to  detect,  and 
correct  a  najor  misunderstanding  is  expensive 
in  term  of  money  and  time.  The  concept  of 
prototyping  encompasses  a  variety  of  specific 
techniques  which  facilitate  oorriunication  and 
understanding  bctwacn  users  and  developers. 

The  nan-machine  interfaces  of  a  system 
are  particularly  critical  to  the  success  of 
its  development  effort.  They  are  cxrplcx,  and 
contain  a  wealth  of  detail.  Prototyping  is 
beneficial  for  determining  detailed  input  and 
output  requirements  and  man-machine 
interaction  requirements.  The  use  of 
prototypes  can  help  identify  and  discriminate 
among  which  functions  the  user  can  effectively 
control  and  which  functions  the  system  noeds 
to  perform  automatically.  Prototypes  of  the 
man-machine  interface  can  also  be  used  for 
early  training. 

Sovaral  characteristics  of  system 
developments  influence  the  relative  benefits 
of  using  prototyping  techniques: 

o  Application  area 

o  Application  carpi exity 


o  Customer  characteristics 

o  Project  characteristics 

"In  general,  any  application  that  creates 
dynamic  visual  displays,  interacts  heavily 
with  a  nan  user,  or  demands  algorithms  or 
combinatorial  processing  that  must  bo 
developed  in  an  evolutionary  fashion  is  a 
candidate  for  prototyping"  (PRES87).  Many 
CDXM  syst/sns  display  such  characteristics, 
and  are  therefore  candidates  for  prototyping 
even  if  they  are  not  following  a  software 
first  approach.  Prototyping  is,  however, 
critical  to  software  first. 

When  building  a  system  using  new  concepts 
or  technologies  Brooks  (BR0075J  contends 

".  .  .  even  the  best  planning  is  not  so 
ceniseient  as  to  get  it  riqht  the  first  time. 
The  management  question,  therefore,  is  not 
whether  to  build  a  pilot  system  and  throw 
it  away.  You  will  do  that.  Ihe  only  question 
is  whether  to  plan  in  advance  to  build  a 
throwaway,  or  to  promise  to  deliver  the 
throwaway  to  customers  .  .  ." 

Pressman  contends  that  a  prototype  can  serve 
as  the  throwaway  system  (PRES87].  This  moves 
prototyping  from  a  luxury  if  one  has  the  tire 
to  an  expected  and  required  learning  expense 
that  can  be  recognized  and  minimized.  Ihe 
prcpocod  software  first  system  development 
approach  echoes  this  conclusion. 

Ihe  remainder  of  this  section  describes 
several  kinds  of  prototyping,  and  relates  them 
to  the  model  of  software  first  presented  in 
FIGURE  2. 
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FIGURE  2.  TOE  FR0K3SED  SOFTWARE  FIRST  SYSTEM  DEVELD  FKEOT  MODEL 
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Ibpcr  Prototypes 

Paper  prototypes  arc  images  on  paper  of 
what  tho  terminal  screens,  reports,  physical 
interfaces.,  and  actual  system  will  look  like. 
Paper  prototype*  provide  a  useful  and 
inexpensive  way  to  improve  communication 
during  requirenent*  definition.  They  are 
appropriate  from  tha  earliest  stages  of  system 
definition.  They  allow  the  interface 
requirements  to  be  determined  before  any 
analysis  or  design  is  done.  They  result  in 
solid  requirements  for  the  man-nadiino 
interfaces  and  in  a  reduced  chance  of 
misunderstanding-induced  requirements  changes 
later  in  tho  life  cycle.  Another  consequence 
of  using  paper  prototypes  is  that 
documentation  of  the  man-machine  interfaces, 
inputs,  and  outputs  will  be  developed  very 
early  in  the  life  cycle  rather  than  after  the 
system  is  built. 

Tho  software  first  approach  to 
retirements  definition  stresses  a  need  for 
the  developer  and  user  to  understand  each 
other  and  to  agree  on  the  system  definition. 
The  paper  prototype  approach  fosters  this 
interaction  by  requiring  the  developer  to 
spend  extra  time  with  the  user  explaining  the 
paper  prototypes  and  listening  to  the  user's 
cements. 

lion  functional  Prototypes 

A  nonfunctional  prototype  is  software 
that  accepts  all  valid  inputs  and  displays  a 
cample  of  each  of  tho  outputs,  but  has  no 
fUnotlraality  behind  tho  displays.  For 
instance,  the  software  may  accept  a  digitized 
image  from  an  external  source  and  display  it 
on  the  screen.  then  the  user  requests  an  FFT 
and  filtering  of  the  imago,  however,  another 
p restored  image  is  displayed  because  the 
processing  software  to  do  the  ITT  and 
filtering  functions  has  not  yet  been 
implemented. 

Within  a  software  first  approach, 
nonfunctional  prototypes  provide  the  same 
advantages  as  do  paper  prototypes:  improved 
communication  and  better  requirements 
definition.  Tho  eventual  users  of  a  system 
can  use  nonfunctional  prototypes  to  get  a  feel 
for  tho  system  being  developed.  If  an 
appropriate  man-machine  interface  is  not 
obvicus  from  discussion  or  paper  prototypes, 
tho  developer  can  provide  a  few  different 
nonfunctional  prototypes  which  employ 
different  man-machine  interfaces.  Feedback 
from  tho  users  can  then  help  determine  the 
proper  approach.  Mora  importantly,  the  users 
can  determine  whether  or  not  the  man-machine 
interface  raps  to  their  conceptual  model  of 
the  task  to  be  accomplished. 

Training  early  in  the  life  cycle  with 
user  feedback  to  the  developers  is  a  key 


component  of  the  proposed  software  first 
approach.  This  can  be  accomplished  by  using 
nonfunctional  prototype*  to  provide  the 
initial  training  for  system  users. 

TUchniqoes  for  building  nonfunctional 
prototypes  include  the  use  of  prototyping 
languages,  4th  generation  languages  or 
conventional  languages.  The  oodc  developed 
for  nonfunctional  prototypes  may  be  reused  in 
the  system,  although  the  primary  purpose  of 
nonfunctional  prototypes  is  to  help  define  the 
system  requirements,  not  to  develop  an  initial 
implementation  of  the  system. 

Marking  Prototypes 

Working  prototypes  have  interface 
capability  and  limited  functionality.  Working 
prototypes  ars  usually  disposable.  They  are 
usually  built  with  a  4th  generation  language 
or  by  exploratory  programming.  They  are  used 
to  explore  feasibility  issues,  such  as  whether 
or  not  a  time  constraint  can  be  ret. 

Working  prototypes  arc  constructed  from 
the  high  Isvcl  design.  Their  applicability  to 
the  software  first  approach  is  in  questions  of 
feasibility.  They  wvy  also  be  used  to  test 
design  options.  Working  prototypes  are 
generally  meant  to  be  used  as  a  learning  tool 
and  then  discarded. 

Development  Prototypes 

A  development  prototype  is  a  program  that 
provides  port  of  the  desired  functionality. 
The  functionality  is  then  augmented  until  tho 
system  is  completed.  This  approach  is  also 
known  as  incremental  development  with  user 
involvement.  The  software  design  must  be 
available  for  tho  development  prototype  to  be 
built. 

Development  prototypes  may  bo  used  to 
establish  requirements  and  then  discarded. 
More  ocmronly,  however,  they  are  used  to 
provide  a  continuous  prototype  for  the  user, 
as  the  prototype  is  developed  into  the 
complete  system.  Such  a  continuously 
available,  evolving  prototype  can  provide  a 
mechanism  for  user  interaction  throughout  the 
development  cycle,  as  emphasized  in  the 
software  first  approach. 

Prototyping  has  also  been  used  to  test 
various  approaches  to  solving  a  problem.  This 
technique  is  also  known  as  exploratory 
programing.  A  developer  who  is  unsure  as  to 
how  best  to  design  or  implement  a  new 
technology  or  deal  with  a  new  requirement  may 
turn  to  prototyping  to  acquire  some  experience 
in  the  area  before  committing  to  a  particular 
development  path.  For  software  first,  this 
applies  to  exploring  high  risk  requirements, 
especially  those  that  affect  the  eventual 
selection  of  hardware  for  the  system. 
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Prototyping  Tool* 

•me  gexU.  of  prototyping  is  no  loam  the 
most  About  a  problem  for  the  lout  cost.  This 
translate*  into  wnting  rorolts  without 
spending  a  lot  of  tine  ceding.  This  issue  has 
been  addressed  by  rodent  developments  in 
techniques  for  rapid  prototyping.  Rapid 
prototyping  anccurwgo*  the  use  of  very  high 
level  languages  and  the  reuse  of  code. 
Included  in  these  categories  are  4th 
generation  languages,  prototyping  languages, 
demonstration  languages,  and  object  oriented 
development  environments  such  as  Smalltalk  and 
Lisp  environments.  The  software  first  system 
development  approach  requires  the  use  of  such 
tools  to  achieve  its  goals  of  improved 
requirements  definition,  better  ocrrunlcation 
between  users  and  developers,  more  careful 
consideration  of  the  man-machine  interface, 
and  early  training,  through  the  use  of 
prototyping. 


PORTABILITY 

Portability  is  a  key  ingredient  of 
software  first.  It  is  both  a  driver  of  the 
philosophy  and  a  goal  of  the  development 
approach.  The  development  of  Ada  as  the  first 
portable  programming  language,  along  with  the 
recognition  that  software  lifetimes  should  not 
be  prematurely  shortened  by  tying  then  Co 
hardware  lifetimes,  together  make  software 
first  both  possible  and  appealing.  The  desire 
to  have  application  software  outlive  its 
initial  target  hardware,  or  developing, 
training,  calibrating  and  maintaining  the 
software  on  the  host  environment,  transform 
software  portability  free  a  nice  ideal  into  a 
requirement. 

This  section  discusses  portability 
definitions,  irplications,  suggestions  for 
increasing  it,  and  finally  measuring  it. 

Definition 

Software  portability  is  the  ease  with 
which  correctly  functioning  software  running 
in  an  environment  can  be  made  to  correctly 
function  in  another  environment.  An 
environment  in  this  context  means  the  hard-are 
and  operating  System  that  the  application 
software  runs  on. 

Although  software  is  often  classified  as 
portable  or  nonportable,  in  reality 
portability  is  a  measure  of  tiw  middle  ground 
between  two  extremes.  The  smallest  amount  of 
effort  to  do  a  port  is  to  recompile  the 
software  for  the  new  target  enviroment.  The 
other  extreme  is  to  translate  or  rewrite  the 
entire  application  while  still  retaining  the 
original  design.  If  the  software  application 
needs  to  be  redesigned  and  rewritten  it  is 
considered  nonportable.  Nonportable  software 
mast  bo  redeveloped. 


Benefits  of  Portability 

portability  provide*  flexibility.  It 
allows  the  customer  to  make  use  of  preferred 
hardware  and  operating  system*.  It  also 
allows  the  upgrade  of  hardware  and  software  as 
dictated  by  changing  needs.  An  environment 
upgrade  could,  for  exasplo,  result  in  the 
ability*  to  process  the  same  amount  of  data 
faster. 

Corputer  hardware  technology  has  and  is 
expected  to  continue  to  improve  at  a  rapid 
rate.  This  has  several  effects: 

higher  clock  rate* 

faster  memory 

new  architecture*  (RISC,  TRACE) 

new  device*  (optical  disks,  OCRs, 

military  unique  device*) 

In  this  climate,  the  environment  choeen 
as  the  target  at  a  project's  inoeption  may  be 
obsolete  by  the  time  the  system  is  fielded. 
Portability  provida*  the  flexibility  to  adopt 
ongoing  technology  advance*.  This  flexibility 
allows  for  greater  choice  (and  competition) 
in  selecting  hardware  platforms. 

Portability  provides  cost  savings, 
particularly  in  the  atintenanoe  phase  of  the 
software  life  cycle.  Software  with  high 
portability  will  have  few  if  any  change*  when 
a  new  release  of  an  operating  system  or  when  a 
hardware  upgrade  is  adopted. 

A  new  class  of  hardware  may  become 
available  with  Improved  price  performance. 
Porting  the  software  to  this  new  hardware  will 
allow  the  system's  performanoo  to  grow  with 
hardware  advances  without  Incurring  complete 
redevelopment  costs.  New  software  technology 
in  compilers,  development  and  maintenance 
tools,  and  operating  systems  will  benefit 
portable  systems.  Taking  advantage  of 
hardware  and  software  technology  advances 
extends  systems'  useful  lives.  All  these 
factors  contribute  to  cost  savings. 

Portability  saves  time.  The  COO  is  often 
locking  for  ways  to  reduce  the  length  of  the 
development  cycle.  Porting  existing  systems 
to  now  hard-are  and  incrementally  extending 
the  systems  capability  is  usually  quicker  than 
building  a  new  system  from  scratch.  This 
revitalization  approach  obviates  same 
development  efforts  and  provides  an  interim 
capability  until  new  systems  are  fielded.  In 
this  way,  portability  can  cave  time  and 
ccqplcnent  the  development  cycle. 

Challenges 

Portable  software  is  not  created  by 
accident.  To  deliver  highly  portable  software 
the  developer  must  consciously  address  the 
following: 
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language  portability 

software  developers'  knowledge  of  machine 
dependencies 

documentation  of  environment  dependencies 
and  assumptions 

nodular  and  parameterized  dependencies 


Language  compiler*  mart  be  available  for 
the  target  machines.  The  language  semantics 
need  to  be  uvoblguously  defined.  The 
language  implementation  aust  not  require 
uncommon  hanksus  features.  For  portable 
applications  it  is  beneficial  to  use  a 
language  which  has  a  standard,  such  as  Ada. 
Vendor  unique  language  extensions  decrease 
portability. 

Programers  need  software  development 
experience  to  generate  portable  code. 
Programmers  typically  go  through  three  levels 
of  cocpc tones.  First,  they  write  the  code  so 
that  it  does  what  they  want  it  to  do.  Second, 
they  understand  how  it  is  that  the  code  thWw 
they  write  instructs  the  machine  to  perform 
appropriately.  Third,,  they  understand  the 
differences  among  target  environments  and 
write  code  that  will  do  what  is  desired  as 
independent  of  the  environment  as  possible. 

For  example,  seemingly  innocuous 
statements  can  present  portability  problems: 

if  (A(x)  and  B(x))  then  ...  endif; 

This  statement  has  several 
interpretations: 

Zf  A(x)  is  FALSE  then  B(x)  will  not  be 

executed 

Either  A(x)  or  D(x)  may  be  executed  first 

Zf  the  first  is  FALSE  the  other  will  not 

be  executed. 

A(x)  and  B(x)  will  always;  bo  executed 

In  sore  applications  the  answers  to  these 
questions  will  effoct  the  results  and/or  the 
performance  of  the  application.  Experience  is 
important  in  writing  portable  code. 

Dependencies  and  assumptions  need  to  be 
documented.  Documenting  serves  two  purposes: 
to  make  the  developer  more  aware  of  the 
dependencies  in  the  code  and  to  aid  developers 
in  porting  the  code  in  the  future. 

Assuming  that  environment  dependencies 
will  oocur  in  the  code,  there  still  are  steps 
that  can  be  taken  to  keep  portability  high. 
One  approach  that  works  well  is  to  localize 
the  nonportable  features  in  modules  separate 
from  the  rest  of  the  functional  code.  Vtocn 
the  software  is  being  ported,  attention  can  be 
focused  on  the  few  nodules  that  contain  the 
dependencies  rather  than  scanning  and  changing 
the  code  throughout  the  system.  Encapsulation 
of  hardware  interfaces  irrto  nodules  also  has 
the  same  benefit. 


Another  approach  to  increasing 
portability  is  to  parameterize  rather  than 
hard  code  information.  This  is  an  accepted 
software  engineering  principle  that  directly 
affects  portability.  An  example  is  where 
there  is  a  location  in  memory  that  has 
information  that  the  system  accesses  from  many 
places  in  the  code.  Directly  (hard)  ceding 
the  address  at  each  place  it  is  referenced 
works,  but  portability  "xuld  be  increased  if 
that  address  were  defined  as  a  constant  in  one 
place  and  the  constant  used  everywhere  else. 

Software  portability  is  affected  by  the 
nature  of  the  function  performed  by  the 
software.  Techniques  to  improve  performance 
are  often  directly  the  opposite  of  portability 
recccwendations.  embedded  systems  often  have 
unique  hardware  interfaces  for  the  devices 
with  which  they  work. 

Another  trade  off  is  developer 
"productivity"  versus  portability.  If  there 
is  a  software  deadline,  developers  will  spend 
less  effort  on  portability  in  order  to  spend 
additional  time  to  develop  functionality.  This 
is  because  most  customers  give  functionality 
higher  priority  than  portability. 

Approaches  to  Isprove  ftartability 

Software  that  verifies  inputs  and  results 
is  easier  to  port.  Robust  coding  ;uds  in 
determining  when  assumptions  are  false  in  a 
new  target  environment.  This  can  save 
debugging  time  when  doing  a  pert. 

Use  available  standards  when  feasible. 
Dcfacto  standards  are  also  helpful.  Use  a 
well  known  approach  rather  than  an  equally 
effective  heme  grown  approach. 

The  code  should  be  easily  understandable 
and  maintainable  by  e  less  experienced  person. 
Understandable  code  is  valuable  when  the 
person  who  does  the  porting  is  different  from 
the  person  who  did  the  development. 

Use  an  approach  which  will  verk  on  the 
broadest  class  of  machines.  The  "standard" 
may  differ  between  two  environments.  In  order 
to  be  portable  e  different  subroutine  my  have 
to  be  called  to  perform  the  sane  function. 

The  design  should  bo  built  such  that  it 
avoids  depending  on  environment  unique 
features.  The  design  roods  to  modularize  the 
environment  dependencies.  The  designer  should 
consider  whether  the  unique  facilities  can  be 
emulated  if  the  software  is  ported  to  another 
environment. 

Performance  Versus  Portability 

Dfpericnooc!  developers  will  trade  off 
some  efficiency  for  portability 
considerations,  because  they  know  that  it  is 
the  cost  effective  approach  in  the  climate  of 
ever  faster/larger/cheaper  hardware. 
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Instability  can  be  isproved  by  using  only 
those  language  constructs  ard  subroutine  calls 
which  are  supported  by  all  envircrrxnts  {all 
the  cnvircments  that  the  systna  is  intended 
to  tun  on) .  This  is  town  as  ccrt-cn 

intersection  or  minimal  suppose  level.  This 
wans  that  the  software  has  to  run  on  the 
poorest  environment  or  even  a  subset  of  the 
poorest  envirertaent. 

For  sundane  prograsninj,  software  can  be 
rode  very  portable.  For  erbodded  systems 
and/or  tine  critical  systems  high  portability 
is  difficult  or  impossible.  "Wien  performance 
is  of  greatest  concern,  and  a  large  rusher  of 
calculations  are  requited,  it  toy  be 
beneficial  to  use  range  constraints  that 
translate  exactly  to  comon  underlying 
hardware  (16  or  32  bit)  to  allow  the  occpilcr 
to  utilise  hardware  overflow  detection  during 
operations"  (GRIE68).  The  current  approach 
with  embedded  systems  is  to  get  the  tost 
capability  and  performance  froo  the  hardware 
available.  The  developers  will  apply  every 
trick  possible  to  provide  the  boss  capable 
system  with  the  hardware  they  havu.  The 
requirements  for  the  system  should  specify 
where  on  this  portability/perfonoroe  speetna# 
the  custceor  would  like  the  system  to  be. 

Long  tor*  solutions  to  the 
porcabil icy/per forsence  tradeoff  are 
continually  being  sought.  One  approach  is  to 
have  military  standard  computers  rather  than  a 
different  architecture  for  each  systen. 
Another  approach  is  for  the  compiler  to  deal 
with  generating  the  »ost  efficient  code. 
Coqpilcrs  continue  to  improve  but  in  Boot 
cases*  are  still  not  as  good  as  a  tew  doiq 
this.  Ada  is  especially  susceptible  to  this 
since  Ada  oocpilers  are  only  about  4  years 
old. 


FIGURE  3  depicts  the  hypothesised 
portability/perforwnoe  curve.  The  llnv  is 
theoretically  the  best  that  can  be  done. 
Si’s  tens  to  the  left  of  the  curve  should  be 
avoided  because  they  can  obtain  additional 
portability  without  sacrificing  pc-fermonoo. 

In  reality  this  graph  nay  have  nany 
parallel  curves  or  contour  lines,  where  each 
line  represents  how  ruth  rcocy  the  customer  is 
willing  to  spend.  Additional  funding  can  buy 
sane  improvmsent  and  shift  the  curve  to  the 
right. 

Real-tine  performance  is  an  area  where 
portability  difficulties  are  obvious. 
Hardware  speeds  vary  and  what  runs  5  seconds 
cn  a  Cray  2  will  take  longer  on  an  I  CM  rc.  If 
t>*o  application  is  insensitive  to  or  flexible 
cn  the  tine  it  takas  to  run  then  it  is  Bore 
portable.  Timing  quirks  also  occur, 
differences  in  device  speeds  can  cause 
problems  with  servicing  and  missing  interrupts 
or  being  interrupted  at 
unexpected/incx&iveniant  times.  This  can 
happen  if  the  new  target  runs  slower  or  faster 
than  the  original  environment. 

Measuring  Portability 

Portability  is  a  function  of  the 
software,  the  original  enviroewent,  and  the 
target  environment.  It  is  sometime*  expressed 
as  the  aaount  of  effort  required  to  be  able  to 
port  the  software.  This  'aaount  of  effort* 
Betric  is  influenced  by  the  knowledge, 
experience,  and  capability  of  the  people 
performing  the  port. 

The  'amount  of  effort'  metric  can  be  used 
with  the  analogy  approach.  The  first  port  of 
the  system  can  be  estimated  using  porting 
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ccwti  for  similar  systetu  and  perscnncl. 
Later  port*  can  be  ba«d  on  sinllar  system 
*rxi  the  pert  history  o(  thi*  system.  »ta*sver, 
this  approach  cannot  be  used  by  the  customer 
In  evaluating  the  portability  of  the  software 
delivered. 

Several  report*  are  available  which 
address  specific  techniques  to  use  and  other 
techniques  to  avoid  when  writing  portable  Ada 
cede  £1815*),  (GRIE88),  (HATW),  (KXSS52), 
(FATJS5). 


caousiass 

One  primary  objective  to  stating  the  full 
wthedolcgy  for  software  first  is  to  provide  a 
framework  into  which  individual  element*  of 
the  software  development  process  can  fit.  In 
this  way,  the  elements,  although  perhaps 
developed  independently,  will  be  consistent 
with  a  single  approach  to  sysren  development 
and,  therefore,  be  mutually  compatible.  Also, 
by  using  individual  dormant*  of  the  software 
first  development  approach,  sane  of  the 
benefits  of  software  first  will  be  achieved. 

Several  el  orient*  proposed  by  software 
first  can  be  implemented  without  adhering  to 
tha  software  first  approach.  For  example, 
prototyping  the  nan  machine  interface  will  be 
beneficial  irrespective  of  the  development 
accroach.  Software  first  neoaMitatac  the 
devdopxnt  of  a  tan  machine  prototype  to 
clarify  requirement*,  to  support  early 
training,  and  to  determine  if  operator*  will, 
in  fact,  be  able  to  operate  the  developed 
system. 

advancing  the  requirements  definition 
process  1s  another  dement  essential  to 
software  first  but  valuable  regardless  of  the 
development  method.  A  shift  toward  formalism 
in  requirements  definition  is  necessitated  by 
software  first  to  decrease  the  ambiguity  of 
requirements,  to  enable  use  of  tools  for 
consistency  checking,  and  to  enhanoe  tha 
maintainability  of  the  requirements  document. 
These  benefit*  are  being  realised  by 
developers  today. 

Prototyping  i*  accepted  alnost 
universally  within  the  software  ooerunity  as  a 
valuable  tool  with  multiple  applications.  For 
software  first  these  applications  include 
avoiding  and  resolving  differences  between 
user  ard  developer  over  interpretations  of 
requirements;  establishing  feasibility  of 
high-risk  requirements;  and  prototyping  the 
can  machine  interface.  Tha  man  rachino 
interface  prototype  will  be  utilirod  and  will 
therefore  need  to  be  a  robust,  functional 
prototype.  Prototyping  is  essential  to 
software  first  but,  obviously,  can  be  utilized 
without  adherence  to  the  software  first 
approach. 


Ada  is  the  most  portable  language  to  have 
been  developed  due  to  the  standardization 
process  for  Ada  compilers.  In  pert  due  to 
Ada,  portable  software  is  becoming  a  reality. 
Measures  for  portability  exist  and  axe 
maturing.  Guideline*  for  enhancing  the 
portability  of  software  exist;  meet  focus  on 
isolating  the  implementation-dependent 
porticos  of  the  system  into  e  limited  number 
of  nodules.  Cne  major  benefit  of  this 
enhanced  portability,  irrespective  of  software 
first,  is  porting  software  to  a  common  support 
environment  for  post  deployment  support. 
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LESSONS  LEARNED  IN  DEVELOPING  REQUIREMENTS 


Garlan  Dealer 


Lockheed  Engineering  and  Sciences  Company 
Space  Station  Freedom-SSE  System  Project 

Abstracl  Requirements  Specification  Life  Cycle 


This  paper  describes  lessons  learned  from 
developing  a  requirements  specification 
document  for  a  large  complex  Ada  system.  The 
requirements  specification  process  is  to  often 
glossed  over  by  the  engineers  so  they  can  dive 
directly  into  the  design  of  the  system.  A 
properly  completed  requirements  specification 
will  drive  the  entire  lifc-cycic  of  the  system. 
The  purpose  of  this  paper  is  to  describe  the 
development  architecture,  methodology  and 
methods  used  during  the  requirements 
specification  process  of  the  Space  Station 
Freedom  Software  Support  Environment  (SSE) 
Project.  The  SSE  requirements  specification 
process  is  explained  with  its  problems  and  with 
some  suggestions  for  a  CASE  tool  to  handle  the 
requirements  analysis  phase. 


The  requirements  specification  phase  is  the 
beginning  of  the  life-cycle  which  effects  the 
entire  life-cycle  of  the  system.  The  purpose  of 
the  requirements  specification  is  to  contain  a 
complete  description  of  the  systems  functions 
without  describing  how  the  system  is 
implemented,  serve  as  the  basis  for  design 
activities,  and  the  basis  for  system  test 
planning.*  Figure  1,  Software  Engineering  Life* 
Cyclc,  shows  how  the  software  requirements 
phase  in  the  software  engineering  life-cyele 
should  be  implemented.  The  software 
requirements  specification  affects  the  entire 
system  life-cycle  because  the  design  and  testing 
of  the  system  arc  developed  from  the 
requirements  specification.  The  software 
requirements  specification  affects  the  entire  life¬ 
cycle  and  a  mistake  in  this  area  can  mean  costly 
mistakes  in  the  other  phases  of  the  life-cycle. 


Figure  1  -  Software  Engineering  Life-Cycle 
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What  is  rcauircimiits_spcciff cation? 

The  requirements  specification  is  a  method 
used  to  describe  what  functions  the  system  will 
perform,  a  means  for  describing  the  workings  of 
a  system,  and  a  way  for  the  customer  to 
understand  the  purpose  of  the  system.  The 
requirements  specification  is  also  used  as  the 
system  basis  for  the  design  and  testing. 
According  to  Vadav,  Urnvoco,  Chatficid,  and 
Rajkumar5  the  requirements  specification  should 
be  described  in  the  form  of:  a  functional  model 
of  the  object  system;  a  data  dictionary  defining 
the  various  components  of  the  functional  model; 
and  set  of  performance  and  test  specifications 
for  the  system. 

What  takes  place  in  the  requirements 
specification  phase  is  the  requirements  analysis 
process  and  requirements  specification 
documentation  production.  The  requirements 
specification  phase  of  the  life-cycle  needs  to 
adopt  a  methodology  for  requirements  analysis, 
and  a  process  to  produce  the  requirements 
specification. 

.Wtiat  is  rmirsmeats , ...analysis.?. 

The  requirements  analysis  is  the  part  of 
the  requirements  specification  phase  that  deals 
with  analysis  of  (he  requirements  to  ensure  the 
systems  objectives  are  met  through  the 
requirements,  and  that  there  are  not  any 
unnecessary,  unwanted  or  ambiguous 
requirements.  There  are  three  basic  questions 
with  respect  to  requirement  analysis:  What 
should  the  requirements  be  (content);  How 
should  requirements  be  stated  (content  form); 
How  should  the  requirements  be  derived 
(content  determining  process).5 

Several  structured  techniques  have  been 
developed  to  help  an  analyst  model  at  the 
requirement  determination  level;  Structured 
Analysis  and  Design  Technique,  Data  Flow 
Diagram  (DFD),  Business  Information  Analysis 
Technique,  Integrated  Definition  Method, 
Interpretive  Structured  Modeling  Software.  It  is 
not  clear  to  educators  and  practicing 
professionals  which  techniques  are  better  suited 
for  requirements  analysis.5  These  techniques 
provide  testing  for  conflicting  requirements, 
ambiguous  specifications,  incomplete 
requirements,  redundant  requirements, 
protocol-deadlocks  between  subsystems,  and 
various  other  redundancies  in  the  system 


specification.  Using  an  object-oriented  approach 
for  the  system  design  can  be  awkward  if 
structured  analysis  techniques  were  used  when 
defining  the  requirements,  since  the  criteria  for 
grouping  functions  arc  different.  The  transition 
from  one  to  the  other  may  require  significant 
recasting  of  the  DFD's.  This  is  a  laborious 
process,  which  can  be  avoided  by  assuming  an 
object-oriented  viewpoint  during  the  analysis 
phase.** 

What  arc  the  requirement  specification 
document _ contents?. 

After  the  requirements  analysis  phase  of 
the  life-cycle  is  complete  a  method  of  reporting 
and  writing  the  processes  from  that  phase  arc 
essential  to  the  requirements  life-cycle  and 
system  development  phase.  The  requirements 
specification  document  addresses  the  findings 
from  the  requirements  analysis.  A  way  to 
represent  and  describe  the  requirements 
analysis  is  the  purpose  for  the  requirements 
specification  document. 

The  requirements  specification  phase  of 
the  life  cycle  will  produce  several  requirements 
specification  documents.  The  requirements 
specification  document  identifies  the  purpose  of 
the  system  and  provides  an  operational  scenario 
of  how  the  system  will  be  used.d  The 
requirements  specification  document  contains 
information  for  the  system  users,  designers, 
implemented,  and  testers  and  it  should  include 
the  following  information.5 

•  Functional  specification  of  what  functions 
the  system  must  perform, 

-  System  context,  Constraints,  and 
Assumptions, 

•  Performance  specification  about  the 
dynamic  properties  of  the  system, 

•  Measurement  and  test  conditions  for  a 
organized  testing  process  to  verify  that  the 
system  is  behaving  properly. 

The  requirements  specification  document 
should  include  context  analysis,  functional 
specification,  and  design  constraints.  Also 
different  types  of  requirements  should  be 
addressed  in  this  document  for  system  design 
and  testing. 

The  next  questions  arc:  What  methodology 
best  suits  the  requirements  specification  phase 
and  how  to  produce  the  requirements 
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specification  document  containing  the 
appropriate  information. 


Introduction  to  the  SSE  Project 

The  SSI;  System  consists  of  host  and 
workstation  computer  hardware,  systems 
software,  communications  networks,  and  SSE 
software.  These  components,  when  integrated 
and  operated  as  a  networked  system,  will 
provide  the  total  life-cycle  management  of  the 
Space  Station  Freedom  Program  software.  The 
SSE  consists  of  software,  standards,  hardware 
specifications,  methods,  procedures, 
documentation,  and  training  capabilities. 

The  contract  for  the  SSE  project  provides 
the  Space  Station  Freedom  Program  with  a 
software  environment  to  aid  in  producing  flight 
and  ground  software  for  the  space  station.  The 
SSE  provides  the  tools,  rules,  and  procedures 
along  with  an  integrated  software  environment 
to  support  the  development  of  application 
software. 

The  SSE  project  is  task  to  deliver  various 
types  of  documents  throughout  the  projects  life¬ 
cycle.  The  SSE  Preliminary  Requirements  and 
SSE  Detailed  Requirements  specification 
documents  arc  the  primary  SSE  requirements 
documents  being  delivered  to  the  National 
Aeronautical  &  Space  Administration  (NASA). 
Knowing  that  requirements  wilt  change  and  may 
change  often  these  documents  will  be  updated 
annually,  after  (he  baseline  is  approved  by 
NASA. 

The  SSE  contract  requires  the  production  of 
approximately  90  documents  during  the  initial 
two  year  term  of  tltc  project.  This  fact  brought 
about  a  great  need  for  a  controlled  document 
development  and  production  process  to  handle 
the  many  developers  working  on  various 
documents. 

The  SSE  System  set  up  in  house  for  the 
document  development  process  consists  of  three 
different  types  of  workstations,  Apollo  Scries 
3000,  Macintosh  II,  and  IBM  PS/2  Model  60. 
These  workstations  arc  connected  to  a  DEC  VAX 
8820  using  an  ethcrnct  Local  Area  Network 
(LAN).  The  LAN  also  includes  the  connection  of 
the  laser  printers  which  produce  hard  copies 
from  the  workstations. 


The  workstations  are  configured  with  word 
processors,  graphics  software,  and  CASE  tools  for 
documentation  development.  The  IBM  PS/2  and 
MAC  II  are  configured  with  the  Microsoft  Word 
word  processor  and  the  Apollo  with  Interleaf  as 
its  word  processing  tool  for  document 
development.  The  graphics  software  used  is 
GBMDraw  for  the  IBM  PS/2,  MacDraw  for  the 
MAC  II,  and  Interleaf  for  the  Apollo.  The  CASE 
tools  available  arc  PowerTools  on  the  MAC  It, 
Teamwork  on  the  Apollo,  and  Excclcrator  on  the 
IBM  PS/2. 

The  LAN  uses  the  File  Transfer  Protocol 
(FTP)  for  transferring  developed  files  from  the 
Apollo  and  the  MAC  II  to  the  VAX,  and  uses 
Kcrmlt  for  files  transferring  from  the  IBM  PS/2. 
The  files  are  then  transferred  and  stored  from 
different  systems  and  applications  using 
interoperability  filters.  Information  on  tool 
interoperability  filers  is  located  in  RlCIS 
Symposium'88  proceedings  under  “Tool 
Interoperability  in  SSE  01  2.0“  .7 

On  the  VAX  the  documents  arc  controlled 
using  the  Automated  Product  Control 
Environment  (APCE)  which  was  developed  and 
supported  by  the  subcontractor  Planning 
Research  Corporation  (PRC).  The  APCE  provides 
an  environment  for  storing,  testing  and 
configuration  management  functions  for  the 
documents. 

This  process  works  because  the  developers 
use  the  workstations  for  word  processing,  DFD, 
and  data  dictionary  development  of  their 
assigned  sections  of  the  documents.  Then  the 
sections  in  a  file  arc  transferred  to  the  VAX 
where  the  developer  loads  the  sections  into  the 
APCE.  Once  in  the  APCE,  the  section  is  ready  for 
testing.  A  tester  checks  the  format  and  content 
of  the  developed  sections  using  the  APCE  as  a 
test  tool.  If  something  is  incoircct,  the  developer 
is  informed  of  the  changes  that  need  to  be  made 
through  VAX  electronic  mail.  This  process 
continues  until  the  entire  document  has  passed 
■the  testing  process  including  final  integration 
tests.  To  produce  a  hard  copy  of  the  document,  a 
VAX  host-based  tool  called  SCRIBE  is  used  to 
print  the  document  on  a  laser  printer. 
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SSE  Methodology  in  Developing 
Requirements  Specification 

The  meth  idology  used  for  developing  a 
requirements  sp  cification  document  for  systems 
using  Ada  begins  with  careful  preparation  of  the 
annotated  outlHe.  A  group  of  three  and  four 
develop  the  inotated  outline  using  a  boiler 
plate  similar  to  the  DID’s  (Data  Item  Description) 
described  in  DOD-STD-2167  for  addressing 
requirements.  The  annotated  outline  identifies 
major  sections  appendices,  system  users,  and 
reference  documents.  The  systems  requirements 
sections  in  the  annotated  outline  briefly  describe 
what  requirerr  nts  will  be  included  in  that 
section.  The  sections  in  the  annotated  outline 
are  analogous  tc  a  process  of  the  system. 

A  book  manager  is  in  charge  of  assigning 
the  appropriate  people  for  developing  the 
different  processes  of  the  system  and  is  in 
charge  of  bringi.  g  the  document  together.  The 
book  manager  d  legates  each  section  to  a  group 
who  will  devek  >  the  requirements.  A  context 
diagram  of  the  system  is  provided  to  develop 
DFDs  for  the  s  ction.  The  context  diagram  is 
usually  obtained  through  the  concept  document, 
proposal,  or  according  to  customer  specifications. 

A  kick-off  meeting  is  conducted  with  the 
people  (developer  &  'esters)  in  involved  in  the 
development  of  'he  requirements  specification 
document.  Durin  the  kick-off  meeting  the  book 
manager  informs  the  developers  of  there 
assignments  and  passes  out  standard  formats 
and  procedures  defined  to  guide  the  developers 
during  the  requirements  specification 
development  process. 

The  developers  begin  collecting  relevant 
requirements  on  the  section  from  system  users, 
contractors,  reference  documents,  and  the 
ustomcr.  All  the  relevant  requirements  arc 
ollected  and  merged  into  a  file.  The  developers 
;  alyze  collected  requirements  to  identify 
processes  which  are  sections  within  the 
document.  The  DFDs  are  developed  for  processes 
and  subprocesses  which  are  analogous  to 
sections  and  subsections  of  the  document. 
Active  entities  should  appear  as  processes, 
passive  entities  as  data  flows;  every  function 
must  be  performed  by  some  entity.6  The 
introduction  of  each  section  of  the  document 
contains  the  mini-  pec  for  the  process  it  is 
associated  with  in  the  DFD.  The  mini-spec 


describes  the  actions  performed  on  the  data 
flowing  into  and  out  of  the  processes.  The 
developers  decompose  requirements,  processes, 
and  DFDs  iteratively  to  accomplish  functional 
partitioning,  functional  decomposition  and 
testing  of  the  system. 

The  requirements  associated  with  each 
process  are  grouped  under  that  section.  The 
Functional  Requirements  explain  what  function 
the  element  will  provide,  the  Detail  Requirement 
clarifies  the  functional  requirement,  the  Single, 
Detailed,  and  Testable  Requirements  specify  how 
fast,  how  many,  and  how  frequently  the 
functional  requirement  will  perform.  Figure  3, 
Requirements  Specification  Document  Structure, 
shows  the  lower  level  document  sections  and  the 
types  of  the  requirements  which  correspond  to 
the  sections. 

In  the  initial  development  phase  of  the 
requirements,  a  complete,  consistent  and 
accurate  statement  of  requirements  for  a  system 
may  be  impossible.  The  reasons  are:  inability  of 
users  to  foresee  all  levels  of  detail,  complexity  of 
the  system;  inconsistency  between  various  user 
viewpoints.4  For  the  unknown  areas  TBD's  (To 
Be  Determined)  will  be  substituted  until 
additional  data  for  the  areas  can  be  defined. 

The  methodology  is  iterative  in  nature  so 
that  the  final  requirements  specification 
document  includes  all  primitive  subprocesses 
and  DFDs  for  each  subprocess.  This  methodology 
allows  for  an  easy  transition  to  the  system 
design  process. 

Once  the  document  is  initially  completed 
the  customer  and  user  community  are  allowed  to 
review  the  requirements  through  a  Review  Item 
Description  (RID).  The  RID  is  a  form  that  allows 
the  customer  to  voice  concerns  with 
requirements  within  the  document.  The  RIDs 
must  then  be  incorporated  into  the  document 
and  again  reviewed  by  the  customer.  When  the 
customer  approves  the  document,  the  document 
is  then  considered  baselined. 

In  practicing  the  above  methodology,  the 
developers  and  testers  encountered  several 
problems.  The  problems  and  recommendations 
arc  presented  in  the  next  section  as  lessons 
learned  in  developing  requirements  specification 
documents  for  a  large  Ada  system. 
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Problem*  Developing _ Rcauirement* 

Specific, a, linn 

The  methodology  explained  above,  though 
fairly  rigorous,  was  not  without  problems,  litis 
scetlon  discusses  the  problems  that  were 
encountered  during  the  requirements 
specification  production  process  and  provides 
several  recommendations  to  avoid  future 
problems.  These  problems  arc  described  below. 

•  During  the  specification  process  frequent 
changes  occurred  to  the  annotated  outline 
while  document  development  was  in  progress. 
This  was  caused  by  a  lack  of  management 
understanding  of  the  requirements 
specification  and  production  process. 
Predefined  standards  for  requirements 
specification  documents  similar  to  DOD-STD- 
2167  should  be  used  produce  an  annotated 
outline.  A  CASK  tool  that  accommodates  a 
frequently  changing  outline  is  required. 
Documentation  bread  board  and  streamlining 
methodology  would  also  help. 

•  Developers'  personal  expertise  was  not  always 
utilized  by  the  book  managers  assignments. 
Making  a  list  of  the  expertise  you  need  and 
match  the  staff  expertise  to  the  section 
assignments  would  make  this  process  easier. 

•  Book  manager  of  the  document  needs  to 
organize  informal  meetings  and  forums  for 
participation  by  the  customers,  and  user 
community  with  the  developers  of  the 
requirements  specification  document. 

•  Lack  of  training  in  the  supported 
methodology  caused  inconsistency  problems 
within  the  document.  Training  for  the 
developers  in  the  chosen  methodology,  and  in 
analysis  techniques  is  required  before 
starting  development  of  the  requirements 
specification  process.  Enforce  project 
standards  for  DFDs  and  provide  a  CASE  tool  to 
adhere  to  these  standards  and  methods. 

•  DFDs  and  data  dictionaries  were  inconsistent 
due  to  lack  of  understanding  of  analysis 
techniques  among  the  requirements 
specification  document  developers.  The  use 
of  a  master  data  dictionary  for  developers 
would  prevent  duplicate  naming  conventions 
and  definitions. 


•  Global  terms  were  inconsistently  defined  in 
the  document.  Create  a  global  glossary  for 
defining  the  terms  used  in  the  requirements 
specification  document,  also  the  glossary 
needs  to  be  controlled  and  maintained  by  the 
book  manager  independent  of  the 
requirements  specification  developers. 

•  Decomposing  of  requirements  and  DFDs  to  a 
testable  level  for  starting  the  design  process 
based  on  Ada.  Not  all  of  these  requirements 
will  be  available  during  the  initial 
requirements  specification  phase.  Inform  the 
customer  of  the  missing  areas  and  proceed  as 
directed. 

•  The  traceability  to  each  primitive 
requirement  to  the  reference  document 
requirements  was  not  well  supported  by  the 
environment,  "traceability  and  reporting 
using  manual  methods  is  a  painful  process".3 
According  to  Stanton3  development  managers, 
project  leaders,  and  engineers  will  spend  over 
403;  of  their  time  preparing  compliance 
documents,  and  most  of  that  time  will  be 
spent  tracing  requirements.  A  CASE  tool  that 
automates  the  recording  of  traceability  for 
requirements  that  change  during  the 
development,  and  after  baselining  of  the 
requirements  specification  document,  is 
necessary. 

•  Reorganization  of  the  document  in  the 
supporting  environment  was  difficult.  Make 
sure  your  CASE  tool  supports  user  friendly 
document  reorganization  and  that  the 
traceability  pointers  move  with  the 
requirements. 

•  Deadlines  were  negotiated  by  management 
and  NASA  at  the  start  of  the  contract  award 
date,  not  by  she  developers.  This  decision 
hurt  the  consistency,  accuracy,  usefulness, 
and  completeness  of  the  document.  However 
often  the  requirements  development  phase  is 
constrained  by  a  deadline  and  a  solution  gets 
picked  without  taking  the  time  to  research 
what  the  customer  requires.4  It  seems  like 
"there  is  never  enough  money  to  do  it  right 
the  first  time  but  there  is  enough  to  do  it 
right  latter".  It  is  best  to  plan  on  more  than 
one  iteration  of  the  document  before 
baselining  the  requirements. 
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*  Requirements  of  the  system  are  dynamically 
being  changed  by  the  customer  during  the 
requirements  specification  process.  Also  note 
that  it  is  not  uncommon  for  the  customer 
(often  the  Government)  to  want  to  change 
“The  Requirement'’  during  development.’*  As 
new  versions  of  the  parent  documents  are 
released  updates  to  the  existing  version  of  the 
requirements  specification  need  to  be 
provided  through  a  CASH  tool. 

Many  of  the  problems  could  be  solved 
using  a  requirements  management  tool.  Actually 
the  biggest  problem  is  establishing  the 
requirements  management  capability  at  the 
beginning  of  the  program  and  making 
requirements  management  part  of  the  whole  life 
cycle.2  A  comprehensive  CASH  tool  for 
requirements  management  to  support  the 
methodology  is  necessary  although  presently 
there  arc  only  tools  to  support  documents  and 
DFD's  independently. 


Requirements  Analysis  ..CASE-Iflol  Criteria 

The  manual  processes  in  the  requirements 
analysis  phase  can  be  reduced  with  a  CASE  tool 
that  avoids  having  to  manually  scan,  interpret, 
and  input  documents,  create  and  maintain  links 
and  pointers,  control  configuration  management 
procedures,  and  transfer  files  to  and  from  other 
systems.2  A  CASE  tool  that  automates  the 
manual  procedures  can  mean  significant  savings 
in  the  amount  of  time  spent  in  the  requirements 
specification  phase. 

A  CASE  tool  that  integrates  the  capabilities 
of  word  processing,  structured  analysis,  and 
object-oriented  design,  that  allows  for  automated 
generation  of  the  requirements  specification 
document  which  includes  traceability  for  (he 
requirements,  and  DFD  generation  corresponding 
to  (he  sections  in  the  document.  A  CASE  tool 
with  those  qualifications  is  what  was  required 
during  the  requirements  specification  phase  on 
this  project. 

A  CASE  tool  for  requirements  analysis  docs 
not  just  provide  links  and  pointers,  that  is  only 
the  beginning.  To  fully  support  requirements 
management,  the  environment  must  also  have 
integrated  text  and  giaphics  editors, 
configuration  management  and  version  control 
facilities,  boilerplate  requirements  tracing  forms, 


enforce  standards  and  control  deliverables,  a 
central  design  database  with  multi-user  access 
and  control.2 

The  following  criteria  is  suggested  for  a 
CASE  tool  to  be  used  during  the  requirements 
specification  process. 

Caic.-lfloL, Criteria 

•  Provides  configuration  management  and 
version  control  facilities. 

•  Provide  for  automatic  checking  in  the 
following  areas:  Static  Structural-signals 
transmitted  through  inappropriate  ports,  or 
signals  received  by  an  entity  but  not  sent  by 
any  entity,  two  requirements  conflict;  a 
specification  is  ambiguous,  incomplete,  or 
redundant,  and  protocol-deadlocks  between 
subsystems.1  Natural  language  does  not 
provide  for  automatic  checking  so  a 
Requirements  Specification  Language  must  be 
used. 

•  The  ability  to  trace  requirements  throughout 
the  system  development  life  cycle  would  help 
solve  many  of  the  significant  problems  facing 
developers  and  managers  such  as:  Planning, 
Development,  Verification,  Communication, 
Project  Control,  Change  Control,  and 
Documentation.2 

•  Create  a  requirements  history  report  and  be 
able  to  report  the  status  of  all  requirements 
in  compliance  reports.2 

•  Integrated  text  and  graphics  editors  within 
the  CASE  tool 

•  Integrates  structure  analysis  and  object- 
oriented  design  techniques  within  the  tool. 

•  Allow  creation  of  boilerplate  requirements 
tracing  forms. 

•  Has  a  central  design  database  with  multi-user 
access  and  control.2 

•  Interactive  entry  and  viewing  of  traceability 
pointers  for  each  individual  requirement. 

•  Individual  requirements  within  different 
versions  of  a  document  and  across  different 
versions  of  configurations.2 

•  Integrated  Automated  document  production 
capability. 

•  Allow  reconfiguration  of  the  environment  to 
enforce  the  adopted  methodology  and 
standards  of  the  project. 

•  Interface  between  a  requirements 
management  system  and  a  document 
management  system  or  a  document 
generation  system.2 


388  7th  Annual  National  Conference  on  Ada  Technology  1989 


•  Automatically  generate  system  level  tests 
directly  from  the  requirements.* 

•  Integrate  a  planning  too!  into  in  environment 
for  planning  of  the  life-cycle  phases 


Conclusion 

Requirements  management  is  a  must  to 
streamline  the  development  and  maintenance  of 
a  large  system.  In  requirements  management 
we  arc  talking  about  system  design  analysis  and 
being  able  to  assess  the  impact  of  an  engineering 
change  request  ICRI. 

The  problems  pointed  out  above  were  not 
deficiencies  in  the  methodology,  but  rather  the 
need  for  planning,  organisation,  developer 
training,  and  the  use  of  automated  methods  with 
a  CASE  tool  to  impose  constraints  and 
standurdisation  during  the  development  process. 
The  solutions  described  above  can  be  provided 
with  the  use  of  current  methodologies  and  with 
the  use  of  a  CASE  tool  which  integrates  word 
processing,  structure  analysis,  object-oriented 
design  and  is  able  to  trace  requirements 
throughout  the  system  development  life-eycle. 
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ABSTRACT 

Ka  describe  the  program  description 
language  Tangraaj  in  St-ne  detail,  in 
particular  we  show  how  Tangram  i  is 
integrated  into  an  object  oriented 
approach  to  software  design  in  Ada. 
Tangram t  is  based  essentially  on  a 
blend  of  SETL's  very  high  level 
diction  and  Ada's  data  and  program 
abstraction  facilities.  We  indicate 
how  Tangra»i  may  be  used  for  program 
generation  as  well  as  for  reusability. 


Introduction 

Programs  can  become  quite  complex,  and  it 
helps  to  have  a  sound  methodological 
approach  to  their  construction.  In  the 
ease  of  Ada  *  there  seem  to  be  two 
competing  approaches  for  managing  this 
complexity:  the  more  traditional  func¬ 
tional  approach,  and  the  object  oriented 
one. 

The  functional  approach  is  an  extension 
of  the  well  known  top  down  design  method 
in  which  functions  and  functionalities 
are  the  primary  objects  of  consideration. 
Dooch  argues  that  this  approach  is  not 
adequate  to  the  linguistic  capabilities 
of  Ada,  and  suggests  the  object  oriented 
approach  t  Dol,  Ch.  2  ) .  The  latter 
approach  is  based  on  objects  and  their 
behavior  as  well  as  on  program  abstrac¬ 
tion  "which  provides  operations  on  an 
object  whose  representation  and  identity 
is  hidden  from  the  user".  [Keg,  p.  257  ). 
Wegner  points  out  that  the  functional 
approach  -  and  correspondingly  the  func¬ 
tional  programming  style  -  lends  itself 
to  support  working  with  functions  in  the 
mathematical  sense  li.o.  working  without 
side  effects) .  The  object  oriented 
approach  on  the  other  hand  night  be 
compared  with  using  mathematical  machines 
(like  finite  state  automata)  in  which  not 
only  the  input  but  some  internal  state 
which  is  hidden  from  the  outside  affects 
the  output.  From  a  practical  point  of  view, 
Dooch  suggests  tho  following  steps  in  an 
object  oriented  development: 

1.  Identify  the  objects  and  their 
attributes. 

2.  Identify  the  operations  suffered  by  and 
required  of  each  object. 

3.  Establish  the  visibility  of  each  object 
in  relation  to  other  objects. 

4.  Establish  the  interface  of  each  object. 

5.  Implement  each  object. 


*  Ada  is  a  registered  trademark  of  the 
U.S.  Government  (Ada  Joint  program 
office) 
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(IB©2,  p.  HU  .Step  3  establishes  the  outside 
viewof  each  object,  and  step-;  its  inside  view, 
so  that  fer  the  purpose  ©f  this  dk.  -ration 
both  steps  nay  be  merged  into  ^  m-'ta  -si.ep 
t4?  it  High  ’•<  :‘:V,-4  f  .*  «'  'f.  In  r.tK- 

ecruccing  the  views,  the  connection  with 
step  2  is  crucial  -  it  has  to  be  firmly 
established  what  the  operations  ©n  each 
object  as  .«  order  to  implement  then. 

The  operations  associated  with  each  object 
should  be  described  in  some  formal  Banner 
before  they  are  implemented.  This  fornal 
description  may  serve  as  an  l 
*h<  ■*;  *<*v*;t  (as  a  blueprint,  so  to 
speak 1 ,  but  under  favorable  circumstances 
may  be  used,  too,  as  a  .*  i*.'e  f  r  r};«-  „Vr'- 
;*;*** n  of  the  implementation  itself.  If 
the  description  is  ©£  a  sufficient  high 
and  formal  level,  and  the  transformations 
can  be  shown  to  be  correctness  preserving, 
it  may  even  be  used  to  f  ‘  ’j  the 

Implementation.  Since  a  description  is 
supposed  to  contain  the  algorithmic  con¬ 
tent  of  a  package,  it  may  be  used,  too, 
for  esjj  rr'v  t h*.  of  the  package's 

code. 

The  practicality  of  such  a  formalism  for 
describing  Ada  packages  hinges  on  conven¬ 
ient  means  of  expressing  the  contents  of 
such  packager  (i.e.  the  objects  implemen¬ 
ted,  and  the  operations  on  and  for  these 
objects).  The  description  should  be 
(otherwise  much  of  its  effect  is  lost! , 

<  rsYnfiJ  (thus  giving  a  basis 
for  verification  and  transformation) ,  and 
ejiff.-rffi*  /  f  i*  jrffi  Jattv-tf  <  (in  this  way 
supporting  the  object  oriented  paradigms) . 

In  this  report  we  propose  a  program 
description  language  (called  Tangrani) 
blending  the  very  high  level  dietien  of 
SETL  with  the  data  and  program  abstraction 
facilities  of  Ada.  Thus  we  advocate  using 
finite  sot  theory  as  an  adequate  way  of 
describing  the  functionality  of  the  opera¬ 
tions  undor  consideration.  The  SETL  expe¬ 
rience  has  shown  that  set  theory  is  a  very 
adequate  notational  tool  for  describing 
the  functionality  of  an  algorithm  without 
cluttering  the  description  with  implemen¬ 
tation  details  (see  e.g.  [  Kru  ]  ,  (SDDS  ] ) . 
This  has  the  obvious  advantage  for  the 
programmor/designor  that  he  may  concen¬ 
trate  on  algorithmic  -  rathor  than  imple¬ 
mentation  -  details.  A  SETb  specif iction 
is  executable,  but  SETL' 3  advantages  of 
notational  convenience  have  to  be  paid  for 
by  a  usually  very  poor  performance.  This 
disadvantage  is  obviated  by  a  combination 
of  tools  to  transform  SETL  programs 

-  the  RAPTS-system  transforming  high 
level  SETL  to  low  level  SETL  (see 
CPaiJ), 

-  the  translation  of  SETL  to  Ada,  con¬ 
verting  executable  specifications  to 
production  efficient  programs  (see 

[ DoGu] ) . 


SETL's  concepts  of  data  types  in  compari¬ 
son  to  Ada's  makes  it  difficult,  though, 
to  blueprint  Ada  programs  (er  packages) 
directly  in  SETL.  Thus  for  capitalising 
on  the  descriptive  power  of  set  theory  in 
the  context  ©f  ©bject  oriented  design  with 
Ada,  it  is  desirable  t©  combine  it  with 
Ada's  data  abstraction  facilities. 

These  remarks  make  it  evident  that 
Tangran  i  uses  an  approach  which  is  rather 
different  from  the  one  used  in  designing 
ANNA  (see  f  LKISd  II:  ANNA  is  a  language 
extensien  to  Ada:  it  works  by  annotating 
Ada  constructs.  In  this  sense,  ANNA  is 
quite  close  to  Ada,  since  important  Ada 
concepts  (scope  and  visibility,  elabora¬ 
tion,  generic  instantiation)  may  be 
applied  t©  ANNA's  annotations.  Ke  will  see 
that  this  is  net  the  case  with  Tangran  i  . 
Doth  ANNA  and  Asphodel  (see  l  IIIL  1 )  are 
languages  with  the  goal  of  supporting  the 
design  of  Ada  programs.  Asphodel  seems  to 
be  based  on  VOM  and  may  be  used  in  an 
annotational  way,  tee.  Its  main  emphasis 
seems  to  he  on  the  formal  verification  of 
specifications,  and  it  uses  models  of 
objects,  which  seem  to  be  similar  to. 
abstract  data  types.  It  remains  to  be 
seen  what  differences  and  similarities 
there  are  between  Tangrani  and  Asphodel. 

This  paper  is  organised  as  follows: 
Section  1  deals  with  the  intent  of  the 
proposed  language.  Here  the  dual  purpose 
ol  blueprinting  programs  and  supporting 
reusability  are  discussed,  and  wq  briefly 
disgress  by  discussing  seme  of  SETL's 
constructs.  Section  2  contains  the  lan¬ 
guage  description  proper.  Here  we  discuss 
in  some  detail  the  language's  descriptive 
mechanisms  in  the  context  of  the  overall 
organisation  of  a  Tangrami  nodule.  Ke 
finally  offer  a  brief  sketch  of  the 
Tangran  system  as  a  system  planned  to 
support  reusability. 

Acknowledgement:  Most  of  the  work  de¬ 
scribed  here  was  done  while  the  author 
was  on  the  faculty  of  the  University  of 
Hildcshein.  The  author  wants  to  thank 
Ms.  S.  Karnrodt  for  her  skillful  typing. 
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I «  Tfr*  Intent  >‘i  a_PragraajP»ae;ri£t.ifia 

£a f^uajjr*  "" 

A  program  description  language  serves 
traditionally  the  purpose  e£  supporting 
the  construction  of  programs,  and  helping 
vith  management  tasks  like  version  ana 
configuration  control  {see  e.g.  {  Win, 

Tie  1  J .  Tangrami  focusses  ©n  the  first  of 
these  aspeets,  negletfes  the  second  one, 
and  makes  an  atter.pt  to  support  reusabil¬ 
ity  instead.  We  will  first  discuss  its 
intent  of  aiding  the  design  of  programs 
(or  program  parts! ,  then  we  are  going  r© 
discuss  its  potential  r@le  in  supporting 
reusability.  Finally  we  want  to  briefly 
disgress  to  SETL  in  order  to  give  an  idea 
of  the  power  of  very  high  level  constructs 
for  program  descriptions. 

l.l  Aid  in  Designing!  Programs 

The  object  oriented  approach  to  program 
design  with  Ada,  as  sketched  opera¬ 
tionally  in  the  Introduction,  ray  be 
characterised  by  a  corblnation  of  data 
and  program  abstraction.  Following  Wegner, 
i:’.i  ;?s'n;«r’  crakes  private  types  and 
operations  on  these  types  available  to  the 
user,  while  ,*r  ..m.m  i'scr;*?:’.  *s  goes  beyond 
that  by  providing  operations  on  objects 
whose  representation  and  Identity  is 
hidden  from  the  user  (  !  Weg,  p.  257 JJ. 

Data  abstraction  la  closely  related  to 
abstract  data  types,  progran  abstraction 
to  generic  packages  and  their  instan¬ 
tiations. 

Dooch's  operationalisation  of  the 
object  oriented  approach  requires  each 
object's  implementation,  after  its  views 
have  been  established.  This  requires  the 
designer  focussing  again  on  the  operations 
associated  with  each  object.  A  progran 
description  language  will  be  of  substan¬ 
tial  help  in  the  design  process  if  the 
connection  between  the  objects  and  their 
operations  is  made  tight  in  the  following 
sense 

-  the  operations  li.e.  functions/proce¬ 
dures)  are  outlined  on  a  functional 
level,  holding  the  balance  between 
going  into  too  nuch  detail,  and  super¬ 
ficially  stating  the  were  intent  of 

an  operation, 

-  the  application  of  data  abstraction 
becomes  visible,  thus  tho  use  of  ab¬ 
stract  data  types  and  their  operations 
are  indicated, 

-  tho  internals  of  this  connection  become 
visible  (comparable  to  the  construction 
of  a  finite  state  machine  in  which  the 
hidden  state  and  the  state  transitions 
which  are  hidden  as  well,  are  never¬ 
theless  specified) . 


The  bare  necessity  of  the  underlying 
language  requires  stating  the  relation 
of  entities  in  the  package  under  consid¬ 
eration  to  other  packages.  This  is  done 
to  ensure  that  entitles  like  variables, 
constants,  types  and  routines  are 
exported  from  the  proper  package,  and 
to  specify  what  entities  are  made  avail¬ 
able  by  the  present  one.  So  this  feature 
should  be  incorporated. 

The  treatment  **f  data  types  and  data 
structures  may  serve  to  illustrate  the 
balance  which  has  to  be  focussed  on  in 
designing  such  a  description  language. 

The  data  structuring  facilities  must  r  tt 
exercise  too  much  generosity  by  not 
restricting  the  user  too  nuch  (since  f'te 
blueprint  aimed  at  might  be  too  sketchy 
to  be  useful),  on  the  other  hand  it  must 
not  force  the  description  of  too  many 
details  (since  in  this  case  flexibility 
might  be  lost) .  Adding  a  second  dimension, 
it  should  be  possible  to  operate  on  dif¬ 
ferent  levels  of  specifity.  Consider 
records  as  an  example:  it  should  be 
possible  to  operate  with  components  of  a 
record  without  being  forced  to  name  them 
(but  using  names  should  be  fine,  too) ,  and 
it  should  be  possible  to  completely 
specify  a  record,  or  to  specify  only  the 
required  components,  which  in  turn  should 
be  allowed  to  contain  type  variables. 

Using  suitable  transformational  tech¬ 
niques,  it  should  be  possible  to  generate 
compilable  Ada  packages  from  Tangram  [ 
descriptions.  This  goal  is  somewhat  simi¬ 
lar  to  the  one  pursued  e.g.  by  the  ESPRIT 
project  SED  (see  e.g.  t  Kel  )  )  using  the 
prototyping  language  SETL.  With  this 
language  used  for  specifications,  one 
starts  with  a  very  high  level  prototype 
(which  is  very  close  to  the  formal  speci¬ 
fication,  hence  easy  to  verify),  and 
gradually  transforms  this  program  into 
a  functionally  equivalent  SET1>  program 
which  is  semantically  on  a  much  lower 
level.  The  transformations  are  correctness 
preserving,  hence  tho  resulting  program 
is  still  correct.  When  further  transfor¬ 
mations  within  SETL  arc  no  longer  prof¬ 
itable,  one  obtains  a  production  efficient 
version  of  the  program  in  Ada  by  a  correct¬ 
ness  preserving  sourco-to-souree  trans¬ 
formation  across  tho  language  boundary. 
This  transformational  approach  is  quito 
attractive,  and  wa  arc  just  gaining  some 
experience  with  it  (now  that  the  tools  ore 
constructed) .  It  docs  not  fit,  however, 
into  the  object  oriented  paradigm  to  pro¬ 
gram  construction.  Let  us  point  out  some 
of  the  differences  between  the  transfor¬ 
mational,  and  the  descriptive  approach: 


* 
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al  transformations  sears  frem  an  exe¬ 
cutable  prototype,  descriptions  are 
net  executable, 

b)  descriptions  are  oriented  towards 
packages  transformations  start  fron 
whole  programs  (although  transforma- 
tiens  may  be  used  technically  on 
partial  pregrams  like  e.g.  5ETL 
modulesl , 

e)  descriptions  use  Ada's  data  struc¬ 
turing  facilities  for  representing 
data  (although  net  exclusively) , 
transformations  start  from  the  reper¬ 
toire  of  finite  see  theory  (i.e.  sets, 
naps,  vectors),  and  select  concrete 
data  representations  only  in  the  very 
last  step,  when  it  cones  to  producing 
an  Ada  program, 

d)  transformations  are  oriented  towards 
functional  behavior  (hence  tend  t© 
follow  a  more  traditional  functional 
approach) ,  descriptions  are  oriented 
towards  describing  objects  and  their 
behavior. 

Consequently,  a  translation  of  Tangracq 
descriptions  into  compilable  Ada  packages 
will  pursue  other  goals  than  the  trans¬ 
lation  ©f  5ETL  programs  into  Ada.  This  is 
essentially  due  to  the  fact  that  the 
translation  SETL*  Ada  makes  only  sense  if 
one  assumes  that  the  prototype  is  the 
complete  solution  to  the  given  problem 
(albeit  one  that  lacks  the  desirable  per¬ 
formance)  while  the  translation  Tangram  i 
•  Ada  works  from  the  more  modest  assump¬ 
tion  that  a  blueprint  describes  part  of 
the  solution  to  a  given  problem. 

1.2  Support  Reusing  Programs 

Tangrani  nay  help  in  supporting  reusabil¬ 
ity.  Reusability  of  software  is  currently 
quite  an  active  area  of  research  in  soft¬ 
ware  engineering,  and  one  of  tho  main 
problems  here  is  to  being  able  to  catch 
tho  meaning  of  a  program,  or  program 
part,  in  order  to  retrieve  programs  by 
their  functionality.  Tho  meaning  of  a 
program  is  difficult  to  characterise 
formally,  and  no  practical  way  of  de¬ 
scribing  it  has  yet  been  devised. 

•-<*  it  it  here  means  in  particular  that  it 
must  be  possible  with  a  reasonable  amount 
of  effort  to  do  the  following  things: 

-  Describe  the  content  of  a  piece  of 
software  in  on  understandable  way 
(i.e.  so  that  not  only  experts  in 
o.g.  ‘-calculus  are  able  to  understand 
the  description) , 

-  Given  the  description  of  a  desired 
functionality,  retrieve  from  o  depos¬ 
itory  of  program  fragments  a  piece 
which  either  has  exactly  the  desired 
functionality,  or  which  comes  closest 
to  it. 


It  in  difficult  t©  see  that  these  require¬ 
ments  will  ever  receive  a  satisfaeto.y 
solution;  there  are  seme  approaches  te  the 
problem  reusability  which  focus  ©n  the 
problem  of  retrieving  components  (e.g. 
tPrFr  1  with  the  •’  'fvs'/;  *:T'  ■-  t  , 

©r  (Malta  1  with  an  approach  using  * 

f'v  techniques).  K©  approach 
known  t©  this  author  deals  In  a  satisfac¬ 
tory  way  with  the  problem  of  describing 
the  meaning  ©f  a  program  fragment. 

There  are  reasons  t©  believe  that 
reusability  ©f  software  will  most  success¬ 
fully  be  undertaken  not  on  the  level  ©f 
the  source  code  ©f  a  pregram  fragment,  but 
rather  on  the  level  of  the  concept  that 
the  program  fragment  is  supposed  t© 
express.  Cheatham  n©tes:  “The  problem  is 
that  programs  in  any  high  level  languages 
are  the  result  ©f  a  napping  from  some 
conceptual  or  abstract  speelfleati©»  of 
what  is  to  be  accomplished  Into  very 
specific  data  representations  and  algo¬ 
rithms  which  provide  an  •?«:•:?  meann 
for  accomplishing  the  tusk  at  hand" 

UChe,  p.  589  ] ).  Hence  one  should  be  able 
te  describe  the  concepts  for  an  Ada  pack¬ 
age,  say,  in  &  suitable  form,  when  it 
comes  to  address  the  question  of  reusabil¬ 
ity  of  the  package.  Tois  conceptual 
description  can  be  done  at  two  different 
points  in  tine:  at  .»  *:.»?«. *,*'  •:  when 

the  mapping  of  objects  and  their  opera¬ 
tions  to  implementations  is  considered, 
and  at  •*.*?;.”  ji-’.j  r?*v,  when  it  comes  t© 
putting  the  package  into  a  software 
depository  for  further  use. 

Using  both  the  ‘  p *©r?  and  the  s 
\  nur'.  r‘  approach  Tangramj,  descriptions 
nay  support  the  process  of  characterising 
software  components.  At  construction  time, 
the  Tangramt  description  of  the  package 
nay  be  used  as  an  approximation  to  a  for¬ 
mal  description  of  the  package's  content. 
At  cataloging  timo  the  process  of  trans¬ 
forming  a  Tangrami  description  into 
compilable  Ada  code,  which  has  been 
sketched  above,  is  reversed.  Given  an  Ada 
package,  one  a  Tangram/  description 
which  faithfully  serves  as  Its  specifi¬ 
cation.  This  requires  of  course  special 
skills  (resembling  the  skills  of  a 
librarian  who  ha3  to  classify  books  for 
inclusion  in  a  library  -  the  analogy 
between  searching  for  a  book  in  a  library 
and  searching  for  a  piece  of  software  in  a 
software  depository  has  been  emphasized  in 
IPrFr )).  Doth  tho  a  priori  and  the  a 
posteriori  description  are  used  then  to 
characterize  the  package's  content  when  it 
comes  to  search  for  a  package  with  a 
specified  functionality. 

K e  will  return  to  this  aspect  in 
Section  3. 
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1.3  v»ry  *t«h  Level  Constructs  (or 
Descriptions 


It  is  obvious  that  programs  written  in  * 
fora* lit*  close  to  formal  spool fications 
«ro  my  to  understand,  and  that  they 
offer  loss  obstacles  to  verification,  than 
programs  written  in  a  formalism  close  to 
a  machine.  Very  hiyh  level  constructs  stay 
be  used  for  such  forMlissts.  These  con¬ 
structs  are  sometimes  supported  by  or 
taken  frost  an  appropriate  Mtheisatical 
theory  such  as  Norn  clause  logic  (-PROLOG, 
see  (Row]) .  A-calculus  (-LISP,  see  (All]), 
array  theory  (*Nial<  see  (  JCH  3  J «  and  set 
theory  (-srrt,  see  (SODS}).  The  descrip¬ 
tive  power  of  set  theory  for  formulating 
algorithm*  has  been  described  and  con¬ 
vincingly  demonstrated  in  thru).  He  will 
focus  on  the  latter  one.  Set  theoretic 
constructs  such  as  set.  maps  and  vectors/ 
tuples  stay  be  used  for  represent ing  data} 
this  together  with  the  familiar  control 
structures  offers  a  rather  natural  way  of 
expressing  algorithms  close  to  their  for¬ 
mal  specifications  (which  may  be  fonulated 
mathematically  using  the  same  apparatus 
anyway) .  Consequently,  we  use  in  Tangraag, 
these  constructs  for  a  convenient  formu¬ 
lation  of  the  algorithms  we  want  to 
represent.  This  means  in  particular  that 
the  process  of  data  abstraction,  i.e.  the 
formulation  of  abstract  data  types  (ADTs) 
is  supported  directly  by  these  constructs. 
He  will  see  how  program  abstraction  is 
supported  by  this  approach!  the  functional 
description  of  routines  provides  opera¬ 
tions  on  the  objects  under  consideration 
without  revealing  their  representation  in 
any  detail. 

Let  us  disgress  briefly  and  give  an 
example  of  the  expressive  power  of  set 
theory  as  realised  in  SETL.  This  should 
give  an  idea  of  what  we  have  in  mind  when 
it  comes  to  concisely  expressing  algo¬ 
rithms.  He  want  to  compute  the  maximal 
cliques  in  an  undirected  graph  S  »  tY,Ei. 


Definition.  A  aubaet  A  e  */  is  eaid  be 
complete  iff  xt  A,y  c4-  (xl  t  (x,yk  S 
h^hjt  then se  is.*.-  diatinsi  Vertiata  art  wontattd 
by  an  <i$al.  A  ia  ejtid  it>  le  a  clique  iff  it  ia 
p.mpUte,  and  a  ivximl  deplete  aei  (i.e.  if 
Ac  If  inpiiea  A  ■  B,  provided  8  ia  replete). 


If  we  want  to  compute  all  cliques  in  0 
in  SETL,  we  may  translate  the  mathematical 
description  into  code  as  follows;  the 
vertices  are  assumed  to  be  given  as  a  set 
v,  the  edges  as  a  set  e  each  elementr  of 
which  is  a  set  of  two  elements.  The  sets 
v and  e  are  read  in;  the  program  prints 
the  set  of  all  cliques  and  is  given  in 
rig.  1. 


Its  salient  features  are 

-  the  explicit  construction  and  use  of 
sets  (and  nested  sets,  too,  e.g. 
complete) ,  and  of  set-theoretic  con¬ 
structs  like  the  element-  or  the  subset- 
relation, 

-  the  use  of  assertions  (if  the  expression 
after  assert  evaluates  to  false ,  the 
program  aborts) , 

-  the  use  of  quantifiers  (v  ,  i), 

-  the  omission  of  explicit  variable 
declarations. 


It  is  easy  to  see  that  this  program  is 
correct.  This  is  so  since  it  is  nothing 
but  a  direct  translation  of  the  mathemat¬ 
ical  problem  specification,  where  the 
relevant  definitions  have  been  expanded 
in  a  macro-like  fashion. 

Using  set-theoretic  constructs  to 
describe  blueprints  for  Ada  packages  will 
introduce  some  special  problems,  as  far 
as  data  structures  are  concerned.  He  will 
use  sets  as  usual  in  mathematics  using 


program  All  Clique*; 
read  (v,  e); 

S 

S  check  to  see  whether  ue  read  In  the  correct 
stuff 


assert  is-set(v  ; 

assert  is«tet(e  and  (  v  edge  c  e  |  (edge  c  v 
and  t  edge  *  2)); 

S  compute  the  set  of  all  complete  subsets 

Complete  :«  (a:  a  r.  v  |  ( v  x  c  a,  y  c  a 
y)  t  e)|; 

S  the  cliques  are  the  maximal  sets  in  Complete 


(x  }  | 


Cliques  :»  (a:  a  e  Complete  |  (not  a  b  «  com¬ 
plete  |  a  c  b  and  a  *  b)J; 
print( Cliques); 
end  program  A. '.Cliques; 


Fig.  1  SETL  program  for  computing 
all  cliques  in  a  graph 


value  semantics:  the  following  code 

A  :■  (1  ....10); 

B  :«  A; 

A  less  :■  10; 

will  not  result  in  removing  10  from  B.  This 
works  fine  as  long  as  no  indirection  is 
involved,  but  there  are  some  difficulties 
as  soon  as  the  sets  in  question  contain 
pointers.  He  will  return  to  this  problem 
in  due  course. 
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2.  Lancuaoa  OMCfl|ttoa 

This  section  win  describe  Tangrami 
trttur  detail.  We  will  first  have  a  look 
at  the  overall  organisation  of  a  Tangram  i 
module,  then  we  will  discuss  the  lan¬ 
guage's  type  model.  Roughly,  a  Tangrami 
module  consists  of  a  prelude  section,  and 
of  its  main  chapter.  These  sections  will 
he  discussed  together  -<th  the  functional 
descriptions  for  th-  ttines  of  the  pack¬ 
ages  to  be  blueprin  Finally,  we  will 
have  to  consider  wha  r*ngramt  module 
really  meeea. 

3.1  Oroanisatlon  of  a  Taneram  module 

A  Tang  rax*  module  is  organised  into  a 
Prelude ,  and  a  section  which  we  eall  the 
TiW-lki’iisti.  The  Prelude  establishes  the 
visibility  of  outside  and  hidden  objects 
to  the  module,  and  the  TVCR-sictlon 
I  types,  variables,  constants,  routines) 
indicates  what  .{c  exported  frcr  this 
module,  hence,  what  entities  are  made 
visible  by  it. 

A  module  description  will  have  to  work 
with  three  different  kinds  of  entities: 
with  objects  that  are  being  made  available 
from  other  modules,  with  objects  that  are 
being  made  available  by  the  module  itself, 
but  which  the  module  choosoa  not  to  reveal 
to  the  outside  (hidden  objects) ,  and 
finally  with  abatract  data  types.  ADTa 
play  a  special  role  here  since  they  are 
not  quite  objects  but  rather  templates. 

As  mentioned  in  the  Introduction,  Ada 
packages  may  be  compared  under  the  object 
oriented  approach  to  state  machines,  which 
have  some  input  and  output,  but  which  work 
with  an  invisible  internal  state,  and  in 
which  the  reaction  to  an  input  is  deter¬ 
mined  by  the  input  as  well  as  by  the 
internal  state.  Thus  data  are  hiddsn  as 
internal  states  of  a  package.  On  the  other 
hand,  the  blueprint  for  a  package  must 
account  somehow  for  the  internal  state, 
since  otherwise  pure  functional  descrip¬ 
tions  would  result.  Thus  the  Prelude  of  a 
Tangrami  module  contains  a  provision  for 
describing  such  an  internal  state. 

The  names  introduced  i;\  the  Prelude 
are  visible  throughout  the  module  descrip¬ 
tion,  and  in  addition  operations  using 
ADTs  are  being  made  visible.  For  example, 
if  a  module  uaes  the  ADT  set,  and  this 
ADT  provides  an  operation  called  Insert, 
then  mentioning  *<*.t  as  an  ADT  in  the  Prelude 
will  make  this  operation  visible  (as 
InsertSset). 

The  TVCK-section  contains  the  functional 
descriptions  proper.  Syntactically,  types, 
variables,  constants  and  routines  are 
being  made  visible.  For  routines,  we  use 
Ade's  syntax  for  their  header  lines  (making 
names  and  signatures  of  the  routines  known 
to  the  environment,  hence  establishing 
visibility) .  For  the  routines  involved. 


we  provide  high  level  descriptions  using 
constructs  from  finite  set  theory.  These 
descriptions  are  local  to  etch  routine, 
in  particular  the  names  of  the  objects 
and  entitles  used  are  local. 

2.2  Tangrami 'a  Type  Hodel 

This  section  is  devoted  to  a  brief  dis¬ 
cussion  of  the  type  system  which  is  being 
used  for  Tangrami.  Since  we  want  to 
blueprint  applications  using  Tangrami,  w« 
do  not  want  to  be  too  specific  about  the 
typo  of  certain  variables;  this  advocates 
using  abstract  data  types,  and  type 
templates  much  in  the  spirit  of  SET*,.  On 
the  other  hand,  we  want  to  addrese  enti¬ 
ties  like  components  of  a  record,  say; 
here  we  have  to  be  rather  specific.  Thus 
we  have  to  have  at  our  disposal  Ada's 
types  at  well  as  SETb's. 

This  yields  a  curious  blend.  Suppose 
that  A  is  a  set  of  access  variables  each 
having  a  numeric  component  p .  Suppose 
further  that  wa  take  an  arbitrary  element 
x  in  A  and  increment  x.p  by  1.  Note  that 
we  did  not  touch  the  set  A,  and  that  the 
old  value  of  A  is  the  same  as  the  new 
value  of  this  set  (since  the  addresses 
did  not  change  at  all).  But  aomething  has 
changed,  and  w«  have  to  account  for  the 
strange  effects  in  the  type  system  to  be 
constructed. 

In  what  follows,  we  refer  to  the  grammar 
for  Ada  as  given  in  [AJPOl.We  need  a 
reference  point  for  the  description  of 
Ada's  types,  and  here  we  choose  the 
grammar  above,  but  start  with  the  axiom 
type.deslaraiien.  This  yields  a  context  free 
language  which  we  denote  by  TYfC.  In 
building  up  Tangrami' s  type  system,  we  fix 
an  at  most  countable  set  A  of  type  varia¬ 
bles  such  tha*  the  variables  6  and  p  are 
no  members  of  A,  C  »  ■  (i  ,  P)y  A  is  the  bass 
set  we  will  be  working  with.  Here  6  stands 
for  the  discrete  types  in  Ada,  and  p  for 
the  real  ones.  An  interpretation  connects 
this  to  TYTC  as  follows t 

Definition.  An  interpretation  of  0  it  a 
tup  d  from  (4,  p)  into  P  (TYPE)  euah  tkat  cash  t 
wrd  in  dlt)  derives  fret s  enumeraticn-type-dcft- 
niticn,  and  cash  uord  in  dig)  derive •  from 
real-type-definitien.  A  selection  o  for  an 
interpretation  d  is  a  partial  tup  o  from  (4,P)  to 
TYPE  such  that  oU)c  dlt)  holds  for  all  t  c 
detain  o. 

Interpretations  describe  intuitively 
what  happens  when  enumerative  and  real 
types  are  elaborated;  they  are  not  really 
necessary  in  what  follows  since  selections 
are  so  closely  related:  given  an  inter¬ 
pretation  A  for  G ,  we  may  reconstruct  A 
from  its  selections,  since  plainly 

dlt)  -  lott);o  is  a  selection  for  d  ) 
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holds.  Thus  we  will  da  without  interpre¬ 
tations.  K«  new  describe  type  constructors 
ever  certain  sets. 

Let  if  be  a  set  of  types. 

Definition.  ?  RrcHU  /  i.V  r- '  r>  .vi* 


RiClHlJ-  Cwc'.rf,  <  II*  I. 

ft1,  if  ^ 

At«(H):»  flanarf,  M'iV-*  ,f> 


j.*  flic  e.-f  /  s’* 
fr-rf,  c,? 


,rf 


Ace  lllls-  HaeeeJi,  Ill 

2c  f»:.-  i\  f  ,  /  tl!  j. ;».?» re  r  .  *f.-  /V.i  If. 

Note  that  the  set  Kcc(ff)  is  essentially 
the  base  set  If*  of  all  sequences  over  If. 
but  should  not  bo  identified  with  the 
latter  sot  -  otherwise  it  would  be  impos¬ 
sible  to  Iteratively  building  up  records. 

Using  the  three  constructors  Kce,  Awand 
Act,  one  builds  up  larger  and  larger  set3. 
Now  let  $1*  be  the  least  fixed  point  for 
these  constructs  containing  G  (hence  in 
particular  the  relations 

RcelJIM  cil‘,Aw(lt*l  cm*,AccWi  eW*, 

hold,  thus  M*  is  closed  with  respect  to 
these  type  constructors) . 

For  each  of  the  constructors  mentioned 
above,  wo  are  able  to  extend  the  interpre¬ 
tations  and  selections  given  for  the  base 
set.  Decause  of  the  remark  above,  we  will 
define  only  selections.  These  selections 
will  map  each  of  the  sets  constructed  to 
TVFE  as  follows:  If  the  typo  constructor  is 
Kcc,  then  I  in  a  selection  onKcc(H)  if 
given  (record,  k)t  RaelH),  thorn  exi3t 
selections  41,... 4k  (with  k  length  tht, 
h  *  >u  ...  hi:  ),  and  maps  from  If  to 

thesot  of  all  identifiers  such  that 

t (record,  k>  -  record 

vi'th.Jttf  <h;li 


i'kOt>J:$k(hk>i 
end  record 

holds.  Similarly,  if  the  type  selector  is 
Aia,  then  4  is  a  selection  on  Aw(lf)  iff 
given  (array,  i,o  )c  Ata(ff),  there  exist 
selections  cj,  ...,afc  on  («)  +  (with  k  :* 
length  fill  and  a  selection  t  on  If  such  that 

41  array, i, e)  *  irrayloi(ii),...,oi:(i}:)}ott<a) 


holds.  We  denote  by  :  HU  the  set  of  all 
selections  on  If.  Then;  (Ac? (HI  is  defined 
through  the  one-to-one  correspondence 

4((aceess,i;)):«aKtesj  («<*:", 

where  4  «  r  HU. 

This  captures  most  of  Ada *3  type  system 
(we  did  not  take  care  of  variant  records, 
or  of  task  types) .  Dut  in  the  same  way  we 
may  incorporate  SETL's  type  system  here, 
and  this  is  what  we  are  about  to  do  now. 

For  this,  let  If  be  a  set  of  types,  then 
we  define  in  a  similar  way 

Stall):*  (Uet.ji;  gt  H*», 

Tup  [If  |  :■  (U(ipfc,il;  J  r  II*  l, 

top(lf,K):>  ( Imp, h,l\;  h  t  II, k  t  K). 

Selections  on  these  sets  are  defined  in 
a  rather  canonical  way:  4  is  a  selection 
on  Set(lf)  with  respect  to  a  set  #  of 
selections  on  If  iff 

^fset,fl|..*3bl  -  (4;f^j»,...,4;Q;;’l 

holds  for  suitably  chosen  selections 
41 , . . . ,  4){ «  .  Analogously,  wo  define 

selections  on  Tup  (II)  relative  to  a  set 
:  j  of  selections  on  If  by  4  Uup(c,gl  ■ 
l«l(gi),...,4k(gk)3. 

Denoting  again  the  set  of  all  selec¬ 
tions  on  If  relative  to  u  byj;  (If,  >-,) , 
we  define 

;:(top(lf,K),  r,  ,  -1) :«  II  :.(K,  ?:,  )  -  j:  IK,  H)J). 

i.e.  as  the  sot  of  all  maps  from  i: 

(H,  i.,1  to  ;  IK,  :;D. 

Now  lot  M?  be  the  least  fixed  point 
containing  M*  with  rospect  to  tho  con¬ 
structors  Sit,  Tup,  and  top,  and  denote 
by  1-  (MV)  the  set  of  selections  on  Mv 
based  on  (M* )  as  tho  sat  of  basis 
selections.  This  is  tho  typo  system  we  are 
working  with.  Thus  a  typo  in  Tangramt  may 
formally  bo  considered  as  a  member  of 
;;  (MV ) .  The  salient  features  of  this  type 
system  are  that 

-  it  incorporates  Ada's  as  well  ns  SETL's 
types,  hence  it  is  possible  to  move 
freely  between  the  typo  systems  of  tho 
two  languages  (keep  in  mind  that  we 
have  excluded  variant  records  as  well 
as  tasks,  so  the  inclusion  with  respect 
to  Ada's  typos  is  to  bo  taken  with  a 
grain  of  salt) , 

-  it  allows  formulating  types  that  may 
have  one  or  more  types  variables  as 
components. 
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Equality  may  be  fornulated  in  this  typo 
system  in  such  a  way  that  e.g.  tv©  seta 
containing  pointers  nay  still  bo  consid¬ 
ered  equal  even  if  a  value  pointed  at 
has  changed  in  ©ne  set  (provided  they 
were  equal  before  the  change) .  This  de¬ 
scription  is  rather  formal,  however,  and 
will  be  described  in  another  paper. 

2.3  The  Prelude  Section 

This  section  serves  a  dual  purpose  by 
making  visible  all  objects  which  are 
required  in  the  TCVfi-  section.  This  applies 
to  those  entities  that  are  defined  exter¬ 
nally  (l.e.  in  other  Tangran  i  nodules) 
as  well  as  to  entities  which  are  entirely 
private  to  the  nodule  under  consideration. 
In  addition  the  ADTs  acted  upon  in  the 
TVER  section  are  dolt  with  here.  Conse¬ 
quently,  this  section  is  subdivided  into 
three  parts,  which  syntactically  are 
described  os  follows: 

prelude 

Imports  —  which  entitles  arc  Irportcd? 

IsAOT  —  whleh  ADTs  are  required? 

Hidden  —  wnlch  Internally  defined 
-■  entitles  arc  visible? 

end  prelude; 

The  object  oriented  approach  demands 
making  the  visibility  of  objects  explicit, 
and  this  is  one  of  the  purposes  of  the 
Prelude  section:  whenever  an  object  in  the 
package  under  consideration  needs  to  see 
an  object  from  another  module,  this  is 
the  place  to  specify  it.  It  may  be  some¬ 
what  surprising  to  see  that  hidden  objects 
are  made  public,  but  the  analogy  with 
finite  state  machines  with  objects  may 
help  here:  although  states  and  state 
transitions  of  a  finite  automaton  are  not 
visible  to  an  outside  observer,  it  i3 
nevertheless  necessary  to  deal  with  them 
and  to  explicitly  manipulate  them.  In  the 
samo  sense  it  may  be  necessary  to  acknowl¬ 
edge  that  there  are  specific  hidden 
objects  in  a  package  which  need  to  bo 
manipulated  explicitly.  An  example  indi¬ 
cating  thi3  may  bo  helpful  here:  suppose 
that  a  package  manipulating  a  text  con¬ 
cordance  has  to  be  designed  (see  [  Bol  ]  , 
Ch.  7).  Then  inserting  and  counting  words 
from  a  text  in  this  concordance  requires 
partial  knowledge  of  the  concordance's 
structure. 

Before  describing  those  three  components 
in  greater  detail,  it  should  be  mentioned 
that  all  names  used  in  this  section  are 
visible  throughout  the  package  description 
which  follows. 


The  Irports  Section 

Apart  from  ADTs .this  subsection  lists  all 
those  items  which  are  imported  from  other 
modules.  This  applies  equally  to  constants, 
variables,  types,  and  routines.  Syntacti¬ 
cally,  we  list  first  the  package  with  its 
name,  and  the  all  entities  as  well  as 
their  properties  which  are  imported  from 
it.  This  is  intended  to  clarify  the 
visibility  of  each  object  (which  in  Ada 
proper  is  sometimes  blurred  by  overusing 
use  clauses).  Name  elashe.  which  may  occur 
later  will  have  to  be  resolved  by  quali¬ 
fication,  but  this  is  not  important  here. 
The  syntax  follows  normal  Tangran i  con¬ 
ventions  with  the  additional  provision 
that  roles  are  introduced  into  the  de¬ 
scription.  A  role  is  an  informal 
characterisation  (by  just  one  identifier) 
of  an  entity  using  the  key  word  AetAs , 
as  in  e.g. 

From  OVER-USE:  —  Imparl  from  that  package 
Type  t  ...  Aetfu  queue-buffer; 

Hence  the  type  t  should  be  defined  in  the 
package  OVER-USE.  The  explanation  following 
AetAs  does  not  have  any  formal,  i.e.  syntac¬ 
tical  or  semantical  signifiance  but  may 
bo  thought  of  as  an  informal  reminder  of 
the  role  the  type  i3  intended  to  play. 
These  roles  are  maintained  in  a  separate 
dictionary  which  is  associated  with  the 
package  description. 

Roles  are  not  only  associated  with 
types  but  may  also  be  attached  to  con¬ 
stants,  variables  and  routines  ns  well. 

The  IsADT  Section 

Here  we  make  .no  ADTs  visible.  This  is 
done  by  the  keyword  IsAOT  acting  as  an 
opener  to  this  subsection,  and  a  list  of 
identifiers  which  are  supposed  to  denote 
abstract  data  types.  When  the  name  of  an 
abstract  data  typo  i3  listed  here,  it  is 
assumed  that  a  package  description  with 
this  name  oxists.  The  names  exported  by 
such  a  package  are  then  available  in  a 
qualified  way.  We  will  deal  with  these 
provider  packages  for  ADTs  later,  but  an 
example  may  be  holpful  here:  Suppose  that 
a  package  description  says 

IsADT  Set,  --  (*) 

and  that  the  Set  package  makes  the  fol¬ 
lowing  entities  available: 

Empty,  —  the  empty  set 

Intersection,  Union,  InsertElement, 

DeleteElement, 

QueryElenent,  Initial izeEmpty  --  usual 
—  operations  on  sets 

Then  the  specification  (*)  makes  in 
addition  to  Set  the  objects  SetSEmpty, 
SetSIntersection  etc.  available. 
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ADTs  My  b«  paraMtriied  by  a  type  or 
by  another  ADT  (e.g.  Qveus  { a  )  denoting 
qua v>«a  with  claaanit  of  typa  a).  That* 

AOTa  ara  Mde  availabla  here,  toot  tha 
peraMter  than  My  aarva  aa  a  forward 
rafaranca  to  tha  TVCR-aaction  whara  tha 
corresponding  typa  ia  axplainad  in  greater 
dataii.  If  otia  (or  mor a)  of  thaaa  para- 
Mtara  ia  inatantiatad  to  a  typa  airaady 
introduced  (a  known  typa) ,  than  anothar 
U$»  ah»!i\}«i  AOT  ia  dafinad.  Thia  naw 
AOT  inharlta  all  oparationa  from  ita 
parant  ACT.  how  thia  ia  indicatad  syn- 
tacticaliy  My  ba  aaan  froai  tha  example 
diaplayad  in  Fig.  2. 

Tha  Hidden  Sac  Hon 

In  taraiA  of  tha  antitiaa  airaady  viaibia 
which  ara  aithar  imported  or  com  froai 
AOTa  it  ia  uauaiiy  nacaaaary  to  Mka  aoat 
internal  objccta  availabla.  Sinca  pack¬ 
age  a  My  ba  aasuMd  to  work  on  aoM  hidden 
internal  state,  an  explanation  of  a  pack¬ 
age'  a  internal  working  ahould  to  bom 
extant  ba  baaed  on  tha  knowledge  of  that 
atata.  Thia  ia  what  happena  hara.  Tha 
analogy  to  tha  private  part  of  a  package 
apacification  of  an  Ada  package  comb  to 
mind.  Tha  private  part  ravaala  tha  imple- 
Mntation  of  a  data  atructura  aa  far  aa 
nacaaaary  for  type  checking.  The  objecta 
declared  hare  aa  hidden  ravaal  in  a 
similar  way  their  internal  atructura  only 
to  tba  extant  which  ia  required  by  tha 
context  (i.a.  to  Mke  namaa  viaibia). 

Nance  both  parte  are  aoMwhat  aimilar 
indeed,  although  tha  aimilarity  comb 
from  different  motivationa. 

2.4  Tha  TVCR-Section 

After  having  outlined  what  antitiaa  ara 
imported  from  tha  package  under  consid- 
cration  -  hereby  eatabliahing  paaaive 
viaibility  -  it  becoMa  neacaaary  to 
eatabliah  active  viaibility.  Thia  aervea 
the  dual  purpoae  of  completely  cstab- 
liahing  the  viaibility  for  each  object, 
and  of  outlining  the  interface  together 
with  a  functional  daecription  for  each 
object. 

Thia  aaction  tails  the  world  outside 
which  types  ara  exported,  where  the 
aemntica  of  the  types  involved  follows 
the  outline  given  above.  Hence  a  blend  of 
Ada's  and  SETL's  types  My  be  Mde  avail¬ 
able  by  a  package.  This  implies  in  partic¬ 
ular  that  a  Tangramt  type  My  contain 
type  variables.  Substituting  all  type 
variables  for  types  proper  evidently 
correspond  to  instantiating  a  generic 
type,  but  it  is  possible  as  well  that 
only  a  partial  substitution  is  done  when 
it  comb  to  use  the  package  within  the 
Tangram  i  system.  Thia  would  correspond  to 
a  partial  instatiation  and  does  not  have 
a  formal  counterpart  in  Ada.  Syntactically 
we  follow  here  much  of  Ada's  syntax  with 


som  modifications.  These  modifications 
address  tha  handling  of  records. 

If  we  aay  e.g.  that 

typa  tsu  is  record 

integer;  res); 
end  record; 

then  it  is  implied  that  among  the  compo¬ 
nents  of  the  record  type  representing  tsu 
at  impleMntation  time  there  will  ba  a 
component  of  type  integer,  and  a  component 
of  type  res)  ,  respectively.  If  v  is  a 
variable  of  type  tsu,  thenv.fl  denotes 
the  component  of  type  integer,  and  v.#2 
denotes  tha  component  of  type*  res),  reap. 
Instantiating  this  record  template  will 
take  care  of  consistent  naming.  In  this 
way  we  hope  to  at  least  partially  bypass 
Ada's  restrictions  with  respect  to 
records  aa  generic  paraMtera. 

This  section  contains,  too,  those  type 
definitions  which  have  to  be  filled  in 
because  of  forward  references  in  tha 
IsAOT  section. 

Tha  declaration  of  variables  and  of 
constants  follows  rather  tha  saM  pattern 
as  tha  corresponding  declarations  in  Ada 
do.  Hare  it  ahould  be  noted  that  variables 
»aay  be  paraMtrised  implicitly  according 
to  type  variables  that  occur  as  compo¬ 
nents  of  their  types,  and  that  defining 
a  constant  implies  no  type  variables 
being  involved  in  the  corresponding 
entities. 

This  section  contains  the  signatures 
of  tha  routines  impleMnted  by  and  ex¬ 
ported  from  the  package.  Hence  we  state 
in  this  section  the  routines  together  with 
their  respective  kind  (i.e.  function  or 
procedure),  the  naMi,  modes  and  types  of 
their  paraMtera  as  wall  as  the  typa  of 
the  value  returned,  if  we  are  dealing  with 
a  funccion.  This  header  line  is  formulated 
in  much  the  sax*  way  as  in  Ada,  and  it 
serves  as  an  opener  to  tha  routine's 
functional  description,  in  which  a  high 
level  outline  of  tha  algorithmic  content 
is  given.  Thin  outline  is  presented  in  a 
manner  resembling  SETL's  diction  of 
expressing  algorithms. 

tfcwill  discuss  details  below,  but 
befors  doing  this,  we  want  to  present  an 
example  which  based  on  Booch's  text 
concordance  problem  (see  [Bol],  Ch.  7  for 
details) .  For  the  sake  of  brevity  we  focus 
on  one  particular  routine  -  the  procedure 
•dd.  The  Tangrami  description  is  given  in 
Fig.  2. 

Thus  we  import  two  types  from  other 
packages  (for  which  we  assume  that  there 
are  package  descriptions  available) ,  and 
make  the  abstract  data  types  set  and  queue 
available.  These  ADTs  are  parametrized 
(the  types  of  the  elements  serve  as  para¬ 
meters)  ,  they  are  instantiated  to  the  ADTs 
queuel,  and  setl,  respectively.  This  implies 
the  availability  of  the  operations  on 
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these  types  ss  discussed  sbove.  The  pack¬ 
age  hss  «  hidden  anonymous  type  and 
another  hidden  object,  vis.,  a  set  x  with 
elements  taken  from  that  type.  All  this  is 
declared  in  the  prelude  section.  The  proce¬ 
dure  sdd  takes  a  word  and  a  line  number 
and  adds  either  the  line  number  to  a  queue 
of  line  numbers,  or  it  adds  the  word 
together  with  an  initialised  queue  to  the 
set  x.  If  the  set  is  full,  an  exception  is 
raised. 

Exceptions  have  to  be  made  visible  in 
much  the  same  way  as  e.g.  types  or  routines. 
This  section  is  the  proper  place  for 
doing  that.  In  the  same  way  as  ANNA  we 
distinguish  three  ways  of  describing  an 
exception.  The  first  way  the  default  wayt 
it  is  just  stated  that  an  exception  is 
raised.  If  the  conditions  are  explicitly 
stated  under  which  conditions  an  exception 
is  raised,  then  we  have  a  s-va?:  description 
of  that  exception.  If  finally  the  package's 
internal  state  is  described  immediately 
before  the  exception  is  raised,  we  con¬ 
sider  this  a  atiwij  description  (see 
CLKNO,  p.  993). 

The  package  description  may  serve  as 
a  very  high  level  draft  of  the  package  - 
it  should  be  evident  from  the  example 
above  that  this  may  be  useful  during  the 
very  first  steps  of  the  design  of  a  pack¬ 
age.  Alternatively,  the  description  may 
serve  to  concisely  describe  the  algorith¬ 
mic  content  of  a  package  for  reusing  it. 
The  functional  description  is  essential 
here,  and  we  will  discuss  it  in  a  moment. 
The  example  also  shows  that  it  should  not 
be  too  difficult  to  generate  executable 
Ada  code  from  the  package  description, 
given  the  experiences  with  generating 
efficient  Ada  code  for  the  version  of 
finite  set  theory  represented  in  SETL  (see 
C  DoGu3) « 


Package  description  CONCORDANCE  is 
prelude 
Imports 

package  WORDS: 
type  word  is  string; 
package  LINE-NUMBERS: 
type  number  is  positive: 

IsAOT  set(g),  queue(h);  —  ADTs  parametrized 
Hidden 

instantiate  queuel  as  queue  (h  >>  LINE-NUMBERS. 

number) ; 

instantiate  setl  as  set  (g  ■>  record  WOROS.word; 

queue  I;  end  record); 

—  This  makes  all  operations  on  the  ADTs 

—  queue(h),  and  set(g),  resp., 

—  available  in  an  appropriate  way 

x:  setl; 
end  prelude; 


procedure  add(the-word:  in  WOROS.word; 

the  number:  in  LINE-NUMBERS. num¬ 
ber); 

functional 

if  exists  k  in  x  such-that  k.ll  ■  the-word 
then  insertSqueuel(k.f2,  the-number); 
else  insert$setl(x,  (the-word,  initializes 
queuel (the-number)); 

when  is-fullSsetl  ■>  raise  overflow; 
fi; 

end  functional; 
end  description  CONCORDANCE; 

Fig.  2  Tangramt  description  for  Booch’a 
CONCORDANCE  problem 


2.S  Functional  Descriptions 

Prelude  and  header  lines  in  a  package 
description  are  quite  oriented  towards 
Ada  (since  this  is  the  target  language 
anyway) .  The  functional  description, 
however,  should  be  concise  and  of  a  very 
high  level..  Nance  it  is  difficult  to  use 
Ada  here,  since  such  operations  as  iter¬ 
ating  over  a  set  and  the  like  are  evidently 
not  available  as  bullt”in  operations  in 
Ada.  On  the  other  hand,  set  theory 
provides  a  very  natural  way  of  expressing 
algorithms.  This  is  so  because  e.g.  sets, 
maps  and  relations  are  easily  used  to 
describe  the  combinatorial  structure 
underlying  all  algorithms.  Consequently, 
it  is  our  hypothesis  that  finite  set 
theory  is  an  adequate  vehicle  for  the 
program  development  process.  This  is 
demonstrated  by  the  SETL  programming  lan¬ 
guage.  SETL,  however,  does  not  fit  directly 
on  top  of  Ada  as  a  program  description 
language  because  it  is  quite  easy  to  loose 
the  link  between  a  SETL  structure,  and  the 
corresponding  Ada  structure  which  is 
intended  to  represent  it  -  and  vice  versa. 
Thus  there  should  be  a  descriptive  level 
between  Ada  as  the  language  to  -implement 
an  algorithm  and  SETL  (or  set  theory)  as 
the  language  to  d t* elite  the  algorithm. 

This  descriptive  level  is  provided  by 
Tangrami,  or,  to  be  more  specific,  by  the 
functional  descriptions  outlining  what 
we  have  called  algorithms  content  above, 
we  borrow  from  SETL  those  constructs 
which  deel  with  sets,  maps  and  tuples. 

The  discussion  of  the  type  structure 
above  shows  that  Ada  structures  may  be 
contained  in  these  set  theoretic  entities 
(so  that  we  may  have  a  set  of  records, 
or  a  map  from  pointer  variables  to  arrays) . 
As  far  as  notation  is  concerned,  we  use 
the  familiar  mathematical  notation  for 
sets  and  tuples.  Hence 

(e(x-l,  ...,  x-k):x-lcc-l,  ....  x-kec-k  | 

P(x-1,  ...,  x-k)} 
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denotes  the  set  of  all  objects  e(x-l,  .... 
x-k)  such  that  x-i  is  taken  from  c-i,  lsisik, 
with  the  property  that  the  predicate 
P(x-1,  ...  ,  x-k)  holds.  Tangram^  provides 
the  usual  operations  on  sets  (union, 
intersection,  set  difference,  power  set, 
inserting  and  deleting  elements,  testing 
membership,  subset  relation  etc.),  and 
on  tuples  (slicing,  concatenation, 
indexing,  to  name  just  a  few)  in  the 
same  way  as  mathematical  set  theory  does. 
Naps  are  the  usual  associative  structures 
and  may  be  used  to  retrieve  image  values. 

The  question  may  arise  here  why  Tangramj. 
provides  set  theoretic  constructs,  but 
allows  sets  as  abstract  data  types  to  be 
formulated.  To  see  why  this  makes  sense, 
wo  have  to  point  out  which  role  is  played 
by  the  different  kinds  of  sets.  When 
formulated  as  ADTs,  sets  are  used  as 
implementation  structures,  so  these  sets 
will  have  to  be  represented  explicitly  in 
the  computer's  memory.  When  used  as  de¬ 
scriptive  structures,  sets  are  used  as 
mathematical  entities  which  not  neces¬ 
sarily  have  to  be  constructed  explicitly, 
but  rather  may  be  trwisifrrmsd  cut,  i.e. 
which  may  be  substituted  after  a  suitably 
chosen  transformational  process  by  simpler 
implementation  structures. 

It  is  possible  in  Tangram  i  to  iterate 
implicitly  over  a  compound  structure  with 
the  existential  and  the  universal  quanti¬ 
fier,  respectively;  existential  and 
universal  quantification  both  yield 
Boolean  values,  the  former  one  producing 
additionally  the  existing  value  if  it 
returns  TRUE. 

In  a  similar  way  we  make  the  usual 
statements  of  a  procedural  language 
available.  This  applies  to 

-  conditional  statements 

(If  ...  then  ...  elslf  ...  then  ...  else  ...  f i ) 

-  cast  statements 

-  iterative  statements  (simple  loops, 
for-,  while-  and  until-  loops) .  These 
constructs  may  be  left  using  a  quit- 
statement,  iteration  may  skip  a  value 
using  a  continue- statement. 

We  want  to  emphasize  the  following  state¬ 
ments  which  may  help  arguing  about  de¬ 
scriptions.  The  assert-statement  takes  a 
Boolean  value  as  an  argument  (e.g., 
assert  xiO)  and  may  consequently  be  used 
to  conveniently  formulate  proconditions. 

An  achieve-statement  also  takes  a  Boolean 
value  as  an  argument  and  may  serve  as  a 
postcondition,  e.g. 

achieve  vied  ...  #t-l)  xuch-that  t{ i )<t( i+1) 

makes  sure  that  the  (dynamic) tuple  t  is 
sorted.  The  achieve-  statement  is  imperative 
in  nature:  saying  achieve  A  means  that  an 
algorithm  has  to  be  devised  that  makes  the 
condition  A  true  (in  contrast  to  assert  A 


which  only  states  that  A  must  be  true) . 

The  select-statement  allows  to  non- 
deterministically  select  an  entity  from  a 
compound  object  like  a  set,  map  or  tuple. 
Tor  example 

select  xct  such-thatv  yet:  x>y 

selects  the  maximal  member  of  t,  where  t 
may  be  a  set  or  a  tuple.  In  analogy  to  the 
achieve-  statement  we  think  of  the  select  as 
imperative  in  nature,  i.e.  an  algorithm 
has  to  be  found  which  takes  care  of  the 
selection.  This  fits  to  the  intent  of 
Tangram  i  as  a  program  description  lan¬ 
guage  allowing  the  formulation  algorithms 
on  a  very  high  level  without  going  into 
too  elaborate  details. 

2.6  Provider-  Packages 

These  packages  are  intended  to  define 
abstract  data  types,  thus  they  previde  a 
service  (rather  than  a  service 

like  an  actor-  package) .  In  a  provider 
package  the  imports  clause  in  the  prelude 
section  is  empty,  since  an  ACT  is  per¬ 
ceived  as  an  independent,  basic  and  thus 
axiomatic  mathematical  entity.  Thus  ADTs 
must  not  depend  on  other  entities.  On  the 
other  hand,  it  does  not  violate  this  per¬ 
ception  of  ADTs  as  axiomatic  entities 
that  the  hidden  clause  in  the  prelude  is  not 
empty,  and  the  IsADT  clause  may  be  present, 
too,  since  an  ADT  may  be  incorporated  by 
another  one.  The  TCVR-section  lists  the 
name  of  the  ADT  together  with  its  para¬ 
meters.  This  name  is  qualified  as  an  ADT 
by  using  ADT instead  of  type,  which  would 
be  used  for  characterizing  type  names  in 
non-provider  packages.  The  functional  de¬ 
scriptions  and  all  other  constructs 
remain  unchanged.  Fig.  3  displays  the 
package  description  for  a  provider  package 
which  makes  the  ADT  set(a)  available.  For 
the  sake  of  simplicity  we  display  only  the 
definition  of  the  operator  *  for  inter¬ 
secting  sets.  Note  the  use  of  the  asser¬ 
tion  that  every  element  of  the  sets 
involved  is  of  the  right  type;  Tangram^ 
provides  a  type  checking  function  (which 
is  of  an  assertive  nature) . 

As  indicated  above,  mentioning  an 
abstract  data  type  in  the  prelude  of  a 
package  description  makes  all  abstract 
operations  on  the  data  type  available. 
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package  description  Set 
prelude 
end  prelude; 

AOT  set(i); 

function  '*"(x:  In  set(e);  y:  in  s*t(a)) 
return  tet(a); 

functionel 

assert  forall  w  in  x  such-thit  type-of(w)  ■  a; 
assert  forall  w  in  y  such. that  type-of(w)  ■  a; 
achieve  x  ■  (b  in  x  such- that  b  in  y  ); 
return  z; 
end  functional; 
end  package  description; 

rig.  3  A  Tangram^  provider  Package 


3)  The  Tang raw  System 

Thin  section  provides  a  brief  overview 
over  the  Tangram  system.  As  the  name 
indicates«  this  system  is  intended  to 
maintain  a  set  of  packages  as  building 
blocks  from  which  programs  may  be  com¬ 
posed.  The  system  is  not  yet  fully 
implemented. 

A  particular  package  is  represented 
.by  its  Tangram t  description;  this  de¬ 
scription  is  intended  to  adequately 
express  the  packages's  intent.  This  is 
not  the  only  aspect  of  a  package  which 
is  stored  in  the  Tangram  system.  Tangram 
collects  different  views  of  a  package, 
and  Fig.  4  indicates  which  views  are 
relevant  here.  Starting  counterlockwise 
from  the  Cede  node,  we  will  briofly 
discuss  each  component  new. 


rig.  k  An  overview  M  Tigran  system 


The  Ada  code  for  the  package  is  stored 
in  the  node  labelled  Cede;  we  store  here 
not  the  textual  respresentation  itself 
but  rather  the  corresponding  abstract 
syntax  tree  -  this  makes  manipulations  on 
the  code  easier.  The  next  node  contains 
role  descriptions,  i.e.  pointers  into  the 
code  where  entities  are  annotated  using 
ActAs.  The  node  labelled  Constraints  indi¬ 
cates  which  restrictions  are  imposed  on 
the  package  (e.g.  which  operating  system, 
which  implementation  restrictions,  what 
storage  capacity  is  required  internally 
as  well  as  externally  etc.)  Those  restric¬ 
tions  are  formulated  in  plain  English  and 
given  in  tabular  form.  The  next  main  slot 
is  occupied  by  a  list  of 
exceptions,  which  in  turn  are  categorised 
according  to  weak,  strong  and  default 
annotations,  as  described  above.  Syntactic 
aspects  are  stored  in  the  next  node,  and 
here  we  focus  on 

-  the  signatures  of  procedures  and  func¬ 
tions,  i.e.  the  list  of  formal  parame¬ 
ters  together  with  each  parameter's 
modes, 

-  the  dependency  graph  for  the  packages 
this  graph  indicates  on  which  other 
packages  the  package  under  consideration 
depends.  These  dependencies  are  cate¬ 
gorized  according  to  packages  provided 
by  the  Ada  system  under  which  the  pack¬ 
age  is  intended  to  run,  and  user 
defined  packages  which  are  maintained 
by  Tangram. 

The  next  slot  is  occupied  by  a  pointer  to 
the  Tangram{.  description  as  discussed  in 
the  present  paper.  Finally  we  find  a  node 
labelled  APU;  here  we  maintain  infor¬ 
mations  about  the  abstract  data  types 
which  are  used  by  che  package  under 
consideration.  This  information  is  pre¬ 
sented  in  textual  form  for  enabling  the 
user  to  determine  what  the  algebraic 
characteristics  of  the  ADT  are;  an 
animated  representation  similar  to  that 
presented  in  the  Balsa-I 1  system  (see 

[Bro  3  )  but  using  animation  techniques 
is  under  construction. 

Tangram  (.  programs  may  obviously  not  be 
used  for  generating  executable  code  on  any 
real  machine.  The  Tangram i  compiler  is 
rather  used  for 

-  consistency  checking:  it  is  checked 
that  importing  and  exporting  objects  - 
hence  making  objects  visible  -  is  done 
properly  and  consistently. 

-  filling  in  slots:  most  of  the  slots  in 
a  node  for  a  package  in  the  Tangram 
system  may  be  generated  automatically. 
If  only  a  Tangram  j.  description  for  a 
package  is  available,  then  these  slots 
may  be  filled  from  the  knowledge  avail¬ 
able  through  this  description. 
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In  addition,  Tangramt  descriptions  will 
•«rv«  a«  an  input  to- the  transformational 
angina  that  darivaa  Ada  programs  from  a 
daacription.  This  will  hava  to  ba  dona  in 
a  vary  similar  way  as  in  [  DoCu  3,  al¬ 
though  soma  sort  of  knowladga  basa  for 
representing  ADTs  and  tha  algorithms 
manipulating  tham  will  hava  to  ba  added. 

Hithin  tha  rasaarch  related  to  Tan- 
gram,  wa  concantrata  first  on  the  de¬ 
scription  of  individual  packages,  since 
wa  faal  that  this  information  is  central 
to  reusability.  Na  hava  not  decided  yet 
how  to  integrate  these  descriptions  into 
a  system  which  supports  retrieving  indi¬ 
vidual  packages.  These  are  at  least  tha 
following  alternatives  to  consider: 

-  tha  faceted  library  mahem  due  to  Prieto- 
Diai  and  Freeman  C  PrFr  ]  which  seams  to 
ba  a  fairly  practical  approach,  although 
it  appears  to  ba  rather  awkward  to  add 
new  categories  to  this  scheme  (in  par¬ 
ticular  to  the  weighted  graph  of 
concepts) , 

-  a  schema  using  conceptual  clustering, 
as  a.g.  Naarak  and  Kaiser  C MaXa  ] 
propose.  This  is  a  very  promising 
approach,  although  it  appears  to  have 
been  tried  out  only  according  to  a 
syntactic  categorization,  rather  than 
on  semantic  categories. 

-  an  approach  oriented  towards  ADTs 
coupled  with  an  expert  system  (quite 
comparable  to  the  SEStiOC  system  devel¬ 
oped  at  GMD  Karlsruhe  in  conjunction 
with  IBH  Germany,  see  £  ZJm  ])  -  here 
it  appears  that  one  would  need  a 
domain  to  argue  about  which  is  somewhat 
more  general  than  ADTs. 

-  an  approach  using  normal  forms,  as  pro¬ 
posed  by  Luqi  and  Ketabchi  [  Luq  3  . 

A  combination  of  conceptual  clustering, 
normal  forms  and  hypertext  techniques  (for 
linking  the  individual  nodes  to  each  other 
in  a  sophisticated  way,  sec  e.g.  [Con  3) 
seems  to  be  the  moat  promising  approach 
and  will  be  pursued  further. 

4.  Conclusion 

He  have  discussed  the  construction  of  a 
*  program  description  language,  and  have 
seen  how  this  language  may  fit  into  the 
object  oriented  approach  to  software 
development  with  Ada.  The  approach  to 
constructing  this  language  centered  around 
the  paradigm  of  developing  programs  using 
a  very  high  level  language  based  on  set 
theory  (much  like  SETL).  Finally  we  have 
indicated  how  the  Tangramj.  descriptions 
fit  into  an  attempt  to  overall  describing 
the  functionality  of  an  Ada  package.  It 
will  remain  to  be  seen  how  this  approach 
may  be  utilized  in  an  integrated  system 


supporting  reusability. 

He  have  pointed  out  that  from  a 
Tangram  i  description  an  Ada  program 
may  be  generated  -  at  least  in  principle. 
Further  research  will  show  how  and  to  what 
extent  the  practical  experiences  gained 
with  translating  SETL  to  Ada  may  be  capi¬ 
talized  upon. 
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AdaL,  An  Automated  Coda  Reuse  System 


George  C.  Harrison 


Norfolk  Stata  Univarsity,  Norfolk  Virginia 


Undar  a  Unitad  Statas  Army  grant  we  ara 
developing  a  prototypa  softwara  packaga 
to  produca  an  automated  Ada  coda  rausa 
systasi  supported  by  tha  language  LIL  to 
aid  tha  Ada  programmer/designer  in  choos¬ 
ing  tha  appropriate  Ada  generic  or  ordi¬ 
nary  packaga  frost  a  data  base  of  reusable 
coda  and  to  automatically  instantiate 
that  coda  if  it  in  generic.  Our  goal  is 
to  have  reusable  coda  chosen  affectively 
WITHOUT  actually  examining  Ada  specifica¬ 
tions.  By  examining  tha  semantics  in  tha 
Lit  files  the  programmer  stay  choose  tha 
appropriate  L1L  file  that  corresponds  to 
tha  spacif icationa  and  sestantic*  needed 
in  his  or  her  Ada  source. 


INTRODUCTION 

The  notion  of  reusing  software,  espe¬ 
cially  source  code,  has  become  an  estab¬ 
lished  practice  in  the  United  States. 
The  tools  to  aid  in  this  practice  have 
not  been  in  wide  use  although  the 

development  of  such  methodologies  are 
attracting  the  attention  of  many  re¬ 
searchers.  Investigators  differ  in  their 
approaches  to  developing  such  tools,  but 
there  is  a  common  thread  of  agreement 
that  efficient  software  should  exist  to 
aid  the  development,  evaluation,  testing, 
storage,  and  integration  of  source  code 
libraries. 2, 5 

Our  investigations  are  concentrating 
on  the  integration  of  reusable  software 
into  ongoing  projects. 3  We  have  been 
most  interested  in  the  reuse  of  Ada 
source  code  and  have  used  Ada  as  the 
primary  development  tool  for  our  user  in¬ 
terfaces  to  the  integration  of  the  stored 
source  code.  This  was  done  out  of  the 
demand  to  'prove"  that  Ada  can  be  used 
effectively  as  reusable  components,  out 
of  the  goals  of  the  supporting  research 
contract,  and  a  bit  out  of  our  zeal  to 
defend  Ada's  qualities. 


grant  from  the  United  States  Army  IARO 
Proposal  •  25S10-EL-H)  by  way  of  the  Army 
Research  Office  and  AIRNICS. 


Por  projects  using  Ada  the  fostering 
ai,d  utilization  of  reusable  packages 
should  be  of  a  primary  concern  and  should 
be  a  common  practice)  however,  if  it  is 
not  easy  to  find  information  about  the 
location,  kinds  and  utility  of  the  source 
code  available  then  they  probably  should 
not  have  been  written.  Yet  another 
problem  arises  when  there  is  a  concern 
about  the  correctness  and  the  ap¬ 
plicability  of  the  code  to  the  overall 
design. 

We  have  also  found  some  frustrations 
in  searching  for  tha  right  piece  of  code 
for  our  applications.  By  scrutinizing  a 
generic  package  we  should  of  course  find 
the  formal  parameters,  the  necessary 
visible  data  types,  the  operations,  and 
the  exceptions.  Even  if  the  code  is  well 
documented  it  is  often  unclear  what  the 
formal  parameters  to  the  generic  package 
represent  and  what  the  limitations  to  the 
semantics  in  the  package  body  are. 


As  an  extreme  example  look  at  this 
generic  complex  operations  package: 


generic 

type  BASE  is  private; 

with  function  PLUS(B1,  B2  :  in  BASE) 
return  BASE; 

with  function  MINUS (Bl,  B2  :  in  BASE) 
return  BASE; 

with  function  TIMES (Bl,  B2  :  in  BASE) 
return  BASE; 

with  function  DIVIDEtBl,  B2  :  in  BASE) 
return  BASE; 


Our  work  has  been  sponsored  primarily 
through  a  sizable  research  and  equipment 


404  7th  Annual  National  Conference  on  Ada  Technology  1989 


package  CMX_OPERATIO.NS  is 

type  CMX  la 
record 

REA  :  DASE; 

IMA  :  BASE; 
end  record; 

function  "-"<2  !  An  CMX)  return  CMX; 

function  COMJUCATEtZ  ;  in  CMX) 
return  CMX; 

function  CMX_TYPE(R  :  in  BASE) 
return  CMX} 

function  REA_PART(7,  :  in  CMX) 
return  BASE; 

function  IMA_PAKT(Z  :  in  CMX) 
return  BASE; 


function  "«"(ZI, 

7.2 

:  in 

CMX) 

return  CMX; 

function  "*"(Z  : 

in 

CMX; 

F  : 

in 

DASE) 

return  CMX; 

function  "*"(F  : 

in 

BASE; 

Z  : 

in 

CMX) 

return  CMX; 

function  “-"tZl, 

7.2 

:  in 

CMX) 

return  CMX; 

function  "-"tZ  : 

in 

CMX; 

F  : 

in 

BASE) 

return  CMX; 

function  "-"IF  : 

in 

BASE; 

Z  : 

in 

CMX) 

return  CMXj 

function  "*"(ZI, 

7.2 

:  in 

CMX) 

return  CMX; 

function  "  *  "  ( 7.  : 

in 

CMX; 

F  : 

in 

BASE) 

return  CMX; 

function  "*"(F  : 

in 

BASE; 

Z  : 

in 

CMX) 

return  CMX; 

function  "/"(Zi, 

Z2 

:  in 

CMX) 

return  CMX; 

function  ’/"( Z  : 

in 

CMX; 

F  : 

in 

BASE) 

return  CMX; 

function  "/"(F  : 

in 

BASE; 

Z  : 

in 

CMX) 

return  CMX; 

function  "••**(*  ;  in  CMX; 

I  ;  in  INTEGER) 

return  CMX; 

ZERO_DIVIDE  :  exception; 

—  rained  when  divisor  is  zero  elenent 

—  in  "/"  functions  and  raised  when  Z 

—  is  zero  elenent  and  I  is  negative 

—  in  the  "**"  function 

procedure  GETtZ  :  out  CMX); 
procedure  PUTCZ  :  in  CMX); 

end  CMX_OPERATIONS ; 


A  nathenntician  niglit  receive  a  lot  of 
enjoyment  manipulating  this  package  by 
repeatedly  instantiating  BASE  with  ar¬ 
bitrary  data  types  and  instantiatin  PLUS, 
MINUS,  TIMES  and  DIVIDE  by  any  four  bi¬ 
nary  operators.  Normally  of  course  such 
a  package  would  only  allow  sone  implemen¬ 
tation  of  floating  point  numbers,  but  the 
package  above  night  be  used  to  work  on 
lattice  points  or  some  mathematical  ap¬ 
plications  where  BASE  night  represent  or¬ 


dinary  complex  numbers  or  the  data  type 
of  4  by  4  matrices  over  the  Integers. 

We  may  not  know  that  the  implementa¬ 
tion  might  make  assumptions  about  the 
BASE  data  type  that  could  either  cause 
run-time  errors  or  erroneous  results. 
For  example  somewhere  m  the  implementa¬ 
tion  there  might  be  an  assumption  that 
the  data  type  has  a  'MULTIPLY'  inverse 
and  identity:  MULT I PLY (01,  INVERSE„U1)  ■ 
identity,  that  MINUS!  MULTIPLY(B1,U2) , 
MULTI PLY ( B2 , 01 )  )  »  the  'ADD'  identity, 
or  that  there  is  a  precedence  of 
operators. 

Ada  has  no  resl  way  of  guarding 
against  had  assumptions  or  against  sup¬ 
positions  about  the  axiomatic  necessities 
of  the  data  types,  operators,  etc.  in  an 
instantiation.  Thus,  we  are  concerned 
that  there  might  he  misinterpretations  of 
the  actions  of  an  implementation  in  a 
reuse  library. 

Our  initial  answer  to  this  problem  was 
to  try  to  use  a  form  of  LIL  (Library  In¬ 
terconnection  Language)  that  provides  and 
extends  many  Ada  semantic  ideas: 
Theories,  Views,  Generics,  etc. I, 3  Al¬ 
though  we  are  still  in  the  process  of 
refining  the  syntax  of  our  form  of  LIL  we 
have  developed  a  prototype  of  a  software 
tool,  Adah,  that  is  primarily  a  user  in¬ 
terface  to  using  LIL  to  support  the 
reusable  qualities  of  source  rode. 


THE  LIL  SPECIFICATIONS 

Normally,  any  implementation  of  AdaL 
would  have  provided  a  hierarchical  col¬ 
lection  of  data  theories  that  could  be 
both  modified  and  added  to  as  the  need 
arises.  For  example  to  "insure"  a  cor¬ 
rect  use  of  the  generic  complex  opera¬ 
tions  package  above  AdaL  might  provide 
the  following  LIL  structures: 


theory  TRIV1AL_SET  is 
type  ELT; 
end  TRIVIAL_SET; 


generic 

type  ELT  is  TRIVIAL  SET; 
theory  BINARY  OPERATION  is 

function  BI_OP  (  El,  E2  :  ELT  J 
return  ELT; 
end  DINAR Y_OPERATION ; 
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generic 

type  H  it  TRIVIAL_SET) 
function  "**  in  BINARY  OPERATION) 
theory  Mono ID  it 

function  (  Ml,  M2  :  M  )  return  H; 
(aaaoc,  id;l); 
end  MONOID) 


generic 

type  M  it  MONOID; 
theory  CROUP  it 

function  "•"  (  Ml,  HI  i  M  )  raturn  M; 
(aaaoc,  inv,  id: 1 >  y 
end  GROUP) 


generic 

type  G  it  GROUP; 
theory  ABBLIAL'jGROUP  it 

function  *•"  (  Gl,  G2  :  G  )  return  G) 
(aaaoc,  coma,  inv,  id : 1 ) ; 
end  ABELIAN.GROUP) 


generic 

type  ELT  it  TRIVIAL  SET; 
theory  SINGLE_VARIABLE~FUNCTION  it 

function  PTN  (  El  :**ELT  )  return  ELT; 
end  «INGLE_VARIABLE_rUNCTIONj 


generic 

type  R  it  ABELIAN.CROUP; 
function  n  it 

SINGLE  VARIABLE  FUNCTION) 
function  "-"  it  BINARY_OPERATION; 
function  it  BINARY_OPERATXON) 
theory  RING  it 
generic 

type  R  it  GROUP; 
view  Aplua 

(  RING  «>  ABELIAN  CROUP  (R)  )  it 
opt  <  "•"  «>  "*"  > ) 
end  Aplua; 

—  Becauae  of  the  traditional  view  of 

—  uaing  +  inatead  of  *  aa  the 

—  operator  in  the  underlying  abelian 

—  group  in  a  ring  we  uae  thin  generic 
--  view  to  change  ita  notation  before 
--  uaing  *  aa  the  nultiplicative  RING 

—  operator 

function  "♦"  (  Rl,  R2  s  R  )  return  R; 

(aaaoc,  com*,  inv,  id : 0 > ; 
function  n  (  Rl  t  R  )  return  R; 
function  <  Rl,  R2  :  R  )  return  R; 
function  "*"  (  Rl,  R2  :  P.  )  return  R; 
(aaaoc) ; 

var  Rl,  R2,  R3  :  R; 


AXiOM 

(right  diatributive  */» 
((Rl  *  R2)*RJ  * 

(R1*R3)  ♦  (R2*R3 ) )  ); 
(left  diatributive  •/» 
(RIMR2  »  R3)  * 

<R1*R2)  *  (R1*R3) )  >) 
(  »(R1)  *  Rlinv  ); 

(  Rl  -  R2  ■  Rl  *  »(R2)  ); 

end  RING; 


The  prograaaaer  now  would  be  in  a  poai- 
tion  to  write  a  L1L  generic  abatraction 
for  GENERIC  COMPLEX  OPERATIONS: 


generic 

type  COMPONENT  la  RING) 
function  "*"  la  BINARYjOPERATIOM; 
function  ia  BINARY  OPERATION) 
function  "•"  it  BINARY  OPERATION) 
function  "/"  ia  BINARY_0PERAT10N; 

package  OENERIC_COMPLEX_OPERATIONS  it 

type  COMPLEX  ia  record 

REAL  :  COMPONENT) 

IMAGINARY  :  COMPONENT) 
end  record; 

function  "-"(Z  :  in  COMPLEX) 
return  COMPLEX) 

function  CONJUGATE (I  :  in  COMPLEX) 
return  COMPLEX) 

function  COMPLEX  TYPE(R  :  in  COMPONENT) 
return  COMPLEX) 

function  REAL  PART* l  :  in  COMPLEX) 
return  COMPONENT; 

function  IMAGINARY  PART(Z  :  in  COMPLEX) 
return  COMPONENT) 
function  "♦"(Zl,  Z2  :  in  COMPLEX) 
return  COMPLEX; 
function  “*"(Z  :  in  COMPLEX; 

F  :  in  COMPONENT)  return  COMPLEX; 
function  "*"  ( F  :  in  COMPONENT; 

l  :  in  COMPLEX)  return  COMPLEX; 
function  •-"(Zl,  Z2  :  in  COMPLEX) 
return  COMPLEX; 
function  "-"(Z  :  in  COMPLEX; 

F  :  in  COMPONENT)  return  COMPLEX; 
function  *-"(F  :  in  COMPONENT; 

Z  :  in  COMPLEX)  return  COMPLEX; 
function  "•"(Zl,  Z2  :  in  COMPLEX) 
return  COMPLEX; 
function  "*"<Z  :  in  COMPLEX) 

F  :  in  COMPONENT)  return  COMPLEX; 
function  "‘"(F  s  in  COMPONENT; 

Z  :  in  COMPLEX)  return  COMPLEX; 
function  "/"(Zl,  Z2  :  in  COMPLEX) 
return  COMPLEX; 
function  "/"(Z  :  in  COMPLEX; 

F  :  in  COMPONENT)  return  COMPLEX; 
function  "/"(F  :  in  COMPONENT; 

Z  :  in  COMPLEX)  return  COMPLEX; 
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{unction  "••"(!  :  in  COMPLEX; 

I  :  in  INTEGER )  return  COMPLEX} 

procedure  GET (I  :  out  COMPLEX) ; 
procedure  PUTCX  :  in  COMPLEX)} 

exception 

DXVISION_BY_XERO} 

var  C  :  COMPLEX} 

X  :  INTEGER} 

*xio#« 

<C  /  (0,0)  >  DIVISION  BY  ZERO)} 

(C  «  (0,0)  and  (INTEGER  0  «> 

POWER (Cl, I)  ■  DXVISXON_BY_lERO); 
(precedence 

0:  ^COMPONENT} 

Is  • COMPONENT,  /COMPONENT} 

2:  ‘COMPONENT,  -COMPONENT})} 

end  GENERIC_COMPLEX_OPERATXONS} 


If  the  programmer  haa  the  following 
Ada  apecif ication  and  body,  we  will  be 
able  to  nake  a  ‘correct"  inatantiations 


{unction  QUOTXENTISl,  82  : 

in  S?)  return  S?  ia 

begin 

eaae  S2  ia 

when  0  ■>  raiae  NOMER I C_ ERROR ; 
when  1  «>  return  SI} 
when  2  *> 

return  S7(1NTEGER(S1)*4  nod  7)} 
when  3  ■> 

return  S7(INTECER(S1)*S  nod  7)} 
when  4  ■> 

return  S7(INTEGER(S1)*2  nod  7)} 
when  5  *> 

return  S7(INTEOER(8l)*3  nod  7)} 
when  6  ■  > 

return  S7(INTEGER(81)*C  nod  7)} 
end  cane} 
end  QUOTIENT} 

end  DATAJTYPE} 


The  uae  o{  viewa  allowa  ua  to  juetify 
how  a  given  L1L  entity  aatladee  a  given 
LIL  theory}  theae  alao  (on  the  (undanen- 
tal  connunlcation  linka  between  LIL  en- 
titiea  and  Ada  conpilation  unite: 


package  DATA.TYPE  ia 

type  87  ia  new  INTEGER  range  0  ,.  <} 

(unction  SUM(Sl,  S2  :  in  S7)  return  87} 
(unction  DirrERENCEtSi,  82  :  in  87) 
return  87} 

(unction  PRODOCT(S1.  82  :  in  87) 

.  return  87} 

(unction  QUOTIENTlSl,  82  :  in  87) 
return  87} 

end  DATAJTYPE} 

package  body  DATAJTYPE  ia 

(unction  SUM(Sl ,  82  :  in  87)  return  87 

ia 

begin 

return  S7( (INTECER(Sl)  ♦  INTEGER (82) ) 
nod  7) } 
end  SUM} 

(unction  DIFFERENCEISl,  82  :  in  87) 
return  87  ia 
begin 

return  87 ( (INTEGER (81)  -  INTEGER (82) ) 
nod  7)} 

end  DIFFERENCE} 

(unction  PRODUCT (81,  82  :  in  87) 
return  87  ia 
begin 

return  S7(INTEGER(S1)  *  INTEGER (82 ) 
nod  7); 
end  PRODUCT; 


—  with  Ada  DATA  TYPE 
View  RXNG_BA8E  t  RING  >>  87} 

typea  1  R  »>  87  ); 
opa  (  «>  ADO  )} 

(  n  ■>  SUBTRACT ( 0 ,  )  )} 

(  «>  SUBTRACT  )} 

(  «>  MULTIPLY  )} 

end  RING_BASE} 

—  with  Ada  DATA  TYPE 

view  PL  :  BI NAR Y_OPERAT ION  »>  SUM} 
typea  (  ELT  «>  87  ); 
opa  (  BX.OP  O  SUM  )} 
end  PL} 

--  with  Ada  DATA  TYPE 
view  MI  :  BINARY_OPERATXON  •>  DIFFERENCE} 
typea  (  ELT  ■>  87  )} 
opa  (  BI  OP  >>  DIFFERENCE  > } 
end  HI} 

—  with  Ada  DATA  TYPE 

view  TI  :  BINARYjOPERATION  «>  PRODUCT} 
typea  (  ELT  «>  87  ); 
opa  <  BI_OP  ■>  PRODUCT  ); 
end  TI; 

—  with  Ada  DATA  TYPE 

View  DI  :  BINARY  OPERATION  «>  QUOTIENT} 
typea  (  ELT  ■>  87  ); 
opa  (  Bl_OP  ■>  QUOTIENT; 
end  DI; 


Note  that  S7  ia  actually  no re  than  an 
ordinary  ring:  it'a  a  finite  field. 
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'View  packages'  Allow  *  named  asaocia- 
tlon  between  LIL  and  Ad*  packages: 


view  package  GCNERIC_COMPLEX  OPERATIONS 
*'  CMX  OPERATIONS 

types  (  COMPONENT  ■#  BASE  1; 
op*  (  *•*  «>  PLUS  1; 

<  «>  MINUS  >; 

<  *•■  «>  TIMES  1; 

t  V"  ■'  DIVIDE  ); 
end  OENERIC..CONPl.EX_OPERATIONS; 


The  uae  of  the  'make'  Hating  allowa 
ua  to  make  a  'correct'  and  automated  Ada 
instantiation.  Thus,  using  the  above 
viewa 


make  COMPLEX  OPERATIONS  is  new 
GENERIC.COMPLEX  OPERATIONS 
(  COMPONENT  ■>  RING  RASE. 
*•“  ■>  PL, 

»>  Ml, 

»>  TI, 

•/*  ■  »  Dl  1;  end> 


automatically  produces  the  following  Ada 
instantiation: 


—  with  LIL  make  COMPLEX  OPERATIONS 
package  COMPLEX_OPERAT:ONS  is  new 
CHX  OPERATIONS 
(  BASE  ->  S7, 

PLUS  ■>  SUM. 

MINUS  ■>  DIFFERENCE, 

TIMES  •>  PRODUCE, 

DIVIDE  «>  QUOTIENT  1} 


This  may  seem  to  be  a  lot  of  work  for 
one  simple  instantiation;  however,  there 
are  three  items  to  remember:  A.  Theories 
only  have  to  be  built  once;  the  more 
theories  implemented  the  fewer  have  to  be 
constructed  for  new  software.  B.  Al¬ 
though  careful  LIL  packages  have  to  be 
constructed  to  match  the  specifications 
AND  the  semantics  of  the  corresponding 
Ada  packages,  they  and  their  correspond¬ 
ing  view  links  to  Ada  become  as  permanent 
as  the  Ada  reusable  code.  C.  The  work 
in  building  views  and  the  corresponding 
'make'  to  use  the  Ada  source  'correctly' 
should  be  well  worth  the  effort  in  system 
integration. 


m  T9<>W 

AdaL  is  a  software  tool  written  in  VAX 
Ada  using  Digital  Equipment  Corporation's 
Run  Time  Library  (RTL)  of  Screen  Manage¬ 
ment  Guidelines  (BMC)  to  facilitate  the 
user  interface.  Fundamentally,  it's  a 
subsystem  to  VMS  that  allows  the  user  to 
work  with  the  reusable  library,  interface 
with  VAX  Ada  commands,  etc.  Me  have  only 
utilised  the  VMS  v4.7  SMG  routines  that 
are  compatible  uitl<  v5.0  SMG  routine*  to 
maintain  compatibility  with  moat  current 
VAX/VMS  systems.  Me  have  attempted  com¬ 
patibility  with  all  VT100,  VT200,  etc. 

terminals. 

Currently,  AdaL  has  the  following 
qualities: 

lh&j£Iggft 

On  a  24  by  10  screen  there  is  a  com¬ 
mand  line  Interface  that  can  be  used  to 
enter  one  of  the  19  commands  or  other 
data  required  by  AdaL.  There  are  five 
pop-down  menus  that  allow  the  user  to 
choose  any  of  the  19  commands. 

Ih2_£29ttfid£ 

£1  opens  an  Ada  file  and  displays  it  on 
the  screen  20  lines  at  a  time.  The  user 
ean  scroll  through  the  file  by  using  the 
cursor  keys  and  the  NEXT  SCREEN  and  PR IV 
SCREEN  keys.  By  moving  the  cursor  to  an 
identifier  and  pressing  the  RETURN  or  EN¬ 
TER  keys  the  user  can  choose  to  use  that 
identifier  as  a  name  or  keyword  to  find 
other  Ada  or  LIL  files  or  to  create  a 
keyword  associated  with  that  file.  The 
default  path  name  to  Ada  files  is  always 
! .ADA_COOE)  and  to  LIL  files  is  always 
I  .LII._COOEl .  These  defaults  can  be 
overwritten  so  that  searching  and  storing 
can  be  accomplished  in  other  locations. 

£2  is  the  same  as  FI  except  that  the  file 
being  viewed  will  be  a  LIL  file. 

£2  is  the  same  as  FI  except  that  any  file 
can  be  viewed.  The  default  path  is  the 
current  path  to  ADAL. 

£4  copies  one  or  more  files.  This  is  es¬ 
sentially  the  same  as  the  VMS  "COPY'"  com¬ 
mand. 

F5  deletes  a  file.  This  is  assent  .ly 
the  same  as  the  VMS  "DELETE"  command. 

F6  renames  a  file.  This  is  essentially 
the  same  as  the  VMS  "RENAME"  command. 

F7  quits  AdaL. 
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U  llata  all  Ada  files  in  (.AOA..COOE) 
with  a  specif 1*4  keyword  associated  with 
thee. 

12  lists  all  LIL  files  in  I. ML _COOEl 
with  a  specified  keyword  associated  with 
thee. 

II  lists  all  ML  and  Ada  files  with  a 
coeeon  specified  keyword. 

£1  Creates  keywords  to  a  specified  Ada 
file;  the  default  path  is  l .ADA_COOE) . 
This  "permanently"  fixes  all  keywords 
created  through  an  PI  eoeeand. 

C2  is  the  same  an  CL  but  for  LIL  files. 

C3  Keywords  created  through  FI.  F2  and  F3 
are  teeporarily  stored  in  a  file  that 
keeps  a  list  of  keywords  chosen  along 
with  the  associated  file  names.  C3  will 
allow  the  user  to  edit  this  file. 

.£1  fixes  all  cowon  keyword  relationships 
among  Ada  and  LIL  files. 

(Not  implemented:  C5,  Cfi  and  C?  which 
will  disassociate  keywords  that  were 
fixed.) 

SI  builds  (edits)  an  Ada  file.  The 

efault  VMS  editor  is  EVE  (EDIT/TPU),  and 
the  default  path  is  I.AOA_COOE).  These 
defaults  can  be  altered.  The  edit  cow¬ 
hands  are  entered  with  unit  names  instead 
of  file  names  along  with  a  choice  of  type 
of  Ada  compilation  unit:  generic  package, 
generic  function,  package,  etc.  New 

files  are  then  created  for  editing  with 
the  basic  structures  already  built  into 
the  buffer. 

B2  builds  a  LIL  file.  The  structure  is 
approximately  the  same  as  Bl.  Unit  names 
and  a  choice  of  type  of  LIL  unit  are  used 
instead  of  file  names. 

B3  builds  an  instantiation  of  a  generic 
unit  in  ( .ADA_COOE]  using  the  associa¬ 
tions  of  the  appropriate  LIL  and  Ada 
files.  The  instantiation  can  then  be 
placed  in  any  directory  for  inclusion  in 
an  Ada  unit. 

HI  displays  the  keyboard  help  screen.  The 
actions  of  special  keys  and  combinations 
of  keys  are  described. 

H2  displays  the  commands  described  here 
and  above. 


(not  Implemented:  01,  02,  03,  04  which 
will  pretty  print,  linking,  compile,  and 
list  unit  closures  and  dependencies.) 


giBfintarelM 

Of  eourse  this  tool  is  very  dependent 
on  VAX/ VMS  routines  and  somewhat  on  the 
conventions  of  the  VAX  Ada  compiler.  Me 
have  plans  to  cut  most  of  these  depen¬ 
dencies  and  plan  on  iwpleawnting  AdaL  on 
HS-OOS  and  UNIX  based  machines. 


mvM_ir.cgg.if 

Besides  the  plans  mentioned  above 
there  is  still  a  large  amount  of  work  in¬ 
volved  in  inserting  this  tool  in  a  prac¬ 
tical  environment.  This  will  mean 
developing  a  more  straight  forward  LIL 
syntax  along  with  more  automation  of  the 
processes.  Me  have  done  some  testing  on 
the  "standard*  stack,  queue,  string, 
search,  etc.  packages  with  some  success. 
Me  feel  the  real  test  will  come  in  using 
AdaL  on  a  "reasonably  large"  project. 
Our  future  plans  also  include  the  writing 
of  a  LIL  syntax  checker  and  sow  sort  of 
natural  language  approach  to  the  search¬ 
ing  process. 4 
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REUSABLE  SUBSYSTEMS  FROM  A 
HIGH  PERFORMANCE  ADA  COMMUNICATION  SYSTEM 
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St.  Petersburg,  Florida 


ABSTRACT 

The  reuse  oT  functionally  equivalent  software  is 
limited  by  performance  and  reliability  requirements. 
The  reusability  can  be  improved  when  the  software 
system  is  designed  for  each  class  of  applications 
following  requirements  established  for  a  reusable 
architecture.  The  reusable  system  is  made  up  of 
functional  object*  and  binding  objects  that  follow  a 
set  of  program  paradigms.  The  functional  objects  and 
binding  objects  in  a  class  of  applications  are  mixed 
and  recombined  to  achieve  the  best  performance  and 
reliability  according  to  the  hardware  and  operating 
system  used  to  drive  the  application. 


INTRODUCTION 

The  data  communication  industry,  more  than  any 
other  industry,  is  obsessed  with  standards  and 
conventions.  It  can  therefore  be  expected  that  there 
is  a  high  degree  of  reuse  of  existing  software  in  this 
industry.  There  is  indeed  a  very  high  degree  of  reuse 
in  this  industry.  This  is  evident  by  the  popularity  of 
SNA  and  DecNcl  However,  there  is  a  continuous 
stream  of  communication  software  being  developed 
from  scratch.  This  is  especially  bothersome  because 
most  existing  network  software  facilitates  the 
installation  of  custom  protocols  where  it  is  required. 

The  need  for  custom  communication  software  is 
justified  by  the  performance  and  reliability  provided 
by  existing  software  •  on  the  hardware  dictated  by 
the  application  •  which  does  not  meet  the 
requirement  of  the  intended  application.  The 
reusability  of  existing  software  is  then  limited  by  the 
performance  and  reliability  when  it  is  installed  on  a 
given  set  of  hardware.  This  paper  presents  an 
approach  that  manages  reusability  and  portability 
for  high  performance  data  communication  software. 


CURRENT  SOLUTIONS 

There  art  two  current  solution*  where  software 
reuse  has  been  successful.  The  first  solution  uses  an 
existing  data  communication  software  system, 
augmented  by  custom  protocols,  that  satisfies  the 
performance  and  reliability  requirements  on  the 
hardware  and  is  acceptable  to  the  functional 
applications. 

The  first  solution  is  most  desirable  as  long  as  the 
hardware  required  to  deliver  the  required 
performance  is  not  limited  by: 

•  Space 

•  Cost 

•  Reliability 

•  Weight 

•  Power  consumption 

•  Processing  speed 

The  second  solution  uses  existing  subroutines  or 
small  software  packages  to  support  reusability  for  a 
new  functional  application.  This  solution  ofTers  very 
little  saving  because  the  majority  of  the  software  cost 
is  in  the  design,  integration,  and  system  test.  Mostof 
the  cost  is  not  in  coding  and  unit  test. 


Another  possibility  is  the  reuse  of  software 
subsystems  from  existing  software  systems  to  build 
high  performance  software  for  specific  applications. 
Approaches  for  using  software  subsystems  as  opposed 
to  whole  software  systems  or  small  software  units  to 
support  reusability  have  not  been  extensively 
studied.  The  advantages,  disadvantages,  and 
problems  associated  with  this  third  approach  are  not 
well  known. 
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CUHHKNT  APPROACHES  TO  INCREASE 
SOKTWAHB  REUSE 

The  current  design  methodologies,  whether  they 
are  structured  or  object  oriented  design,  approach  the 
software  reuse  issue  on  the  following  two  principles: 

1.  Identify  common  functions  through  implemen¬ 
tation  independent  functional  decomposition 
or  object  identification, 

2.  Encapsulate  the  implementation  of  the 
common  function,  discussed  by  Cox  and  Hunt 

m. 

There  has  been  a  fair  amount  of  success  with  this 
approach.  However,  15  years  after  the  introduction 
of  structured  system  analysis,  the  software  reuse 
problem  isstill  a  subject  of  significant  study. 


LESSONS  FROM  SUCCESSFUL  REUSABLE 
SOFTWARE  EKKOKTS 

There  are  many  successful  systems  where  parts  of 
the  system  arc  rearranged,  or  augmented  with  new 
software,  to  form  different  applications.  Most  notable 
are: 

1.  UNIX  PIPE  for  text  file  applications 

2.  Transaction  processing  systems  like  CICS 

These  reusable  software  systems  have  the 
following  common  characteristics: 

•  The  software  is  only  reusable  in  a  Compatible 
class  of  applications.  The  different  appli¬ 
cations  in  the  same  class  can  be  as  diverse  as 
an  air  cargo  system  or  a  bank  debit  system. 

•  A  defined  Binding  Architecture  that  spells  out 
the  different  subsystems  comprising  the 
system  and  defines  how  each  piece  should  fits. 

•  Binding  Objects  that  tie  all  pieces  together  but 
do  not  directly  add  to  the  functional  require¬ 
ments  of  the  application. 

•  Functional  objects  that  are  directly  related  to 
the  functional  requirements  of  the  application. 

•  All  the  functional  objects  and  binding  objects 
are  constructed  to  a  compatible  Program 
Paradigm  for  the  unique  reusable  system. 

•  Portable  Language. 


It  is  interesting  to  note  that  these  successful 
reusable  software  methods  were  developed  before 
structure  programming,  structure  system  analysis, 
and  object  oriented  design  were  introduced  into  the 
software  community. 


Figure  1  shows  how  the  hardware  community  has 
developed  the  capability  to  mix  different  subsystems 
into  an  appropriate  system  that  can  support  multiple 
applications.  This  has  been  supported  with  the 
definition  of  standard  hardware  "Binding"  objects 
that  permit  the  linking  of  various  functional  objects 
to  other  functional  objects.  An  analogy  between  the 
hardware  and  software  community  is  shown  in 
Tables  I  and  11. 
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Table  I  lUu  the  hardware  equivalent*  of  the 
reutablt  sysUm  characterittic*.  Table  It  littt  the 
different  parts  of  the  reusable  software  system 
according  to  the  required  characteristics. 


Table  1.  Hardware  Equivalent  Partition  Example 
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Table  II.  Reusable  Software  System  Partition 
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We  can  also  draw  the  following  observations  from 
these  successful  software  systems  about  software 
reuse: 

a  Easy  rearrangement  of  existing  functions  to 
produce  new  applications  is  n  key  for  software 
reuse. 

a  A  narrowly  defined  class  of  application  is  often 
enough  to  support  the  additional  cost  of  soft* 
ware  reuse. 

#  Exact  match  of  function  is  not  necessary  for 
reuse. 

•  Easy  addition  of  now  functions  is  essential. 


-KKUSAHMi.lllOH  PERFORMANCE 
COMMUNICATION  SOFTWARE  DESIGN 
APPROACH 

The  novel  reusable  software  design  approach 
described  in  this  paper  is  based  on  observation*  of 
limited  reusability  in  both  the  software  and  hard* 
ware  community  and  on  two  considerations  which  are 
not  advocated  in  current  software  engineering 
practice. 

The  first  consideration  is  acknowledging  that  the 
total  software  solution  include*  extensive  amount*  of 
software  executable  code  used  to  support  the  binding 
of  the  functional  application  software  to  each  other, 
to  the  hardware,  and  to  the  operating  system 
services.  In  this  novel  design  process,  there  is  a 
conscious  effort  to  separate  the  purely  functional 
pieces  of  software  from  all  other  software  that  is 
dependent  on  the  hardware  and  operating  system 
environment. 

The  second  consideration  is  that  the  binding  effort 
and  the  selection  of  the  hardware  is  not  a  one  time 
event  in  the  life  cycle  of  a  software  project.  This  is 
especially  true  in  the  high  performance  embedded 
system.  This  point  was  expanded  upon  in  a 
discussion  about  fault  tolerance  and  performance  by 
Chen  and  Sobkiw  (6).  Thus,  if  an  effective 
mechanism  could  be  developed  to  isolate  unique 
"binding  objects  software"  from  "functional  objects 
software,"  then  not  only  will  the  potential  for 
reusability  increase,  but  also  during  the  course  of 
software  development/modification,  the  effort  may  be 
reduced  as  functions  are  bound  in  different  ways  to 
support  various  stages  of  development.  The 
functional  design  or  the  application  and  the 
elaboration  of  the  binding  effort,  a*  well  as  the 
selection  of  the  hardware,  can  be  carried  out  as  two 
independent  activities  if  the  two  interfacing 
activities  are  properly  defined. 


Figure  2  shows  that  there  is  an  area  of  software 
activity  that  eventually  translates  to  unique  code. 
That  software  effectively  allows  the  application  to 
become  integrated  with  the  operating  system  and 
hardware  services.  This  is  shown  conceptually  in 
Figure  3. 
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Figure  2.  The  Software  Acliviiy 

A  wafer  piece  *f  U  overlooked  by  todoyV 
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hardware  reanurcca. 


In  structured  system  analyala  the  functional 
design  ia  bound  to  the  operating  ayatem  and 
hardware  after  an  implementation  Independent 
analyala.  The  aame  can  he  aaid  of  the  OOD 
technlquea  in  which  the  unique  hardware  archi* 
lecture  ia  hound  with  the  mulling  001)  baaed 
design.  Thcae  deaign  approaches  were  driven  by  two 
aMumptiona. 

The  final  aaaumplion  waa  that  the  aoftware  deaign 
start*  with  an  implementation  independent  analyaia 
which  definea  functiona  and  data  flowa.  Then,  the 
aoftware  functions  are  allocated  to  hardware 
resources.  Each  group  or  functions  in  a  hardware 
resource  can  be  allocated  into  aoftware  processes  and 
these  processes  can  be  designated  as  a  collection  of 
procedures  by  structured  system  analyaia  or  other 
techniques.  This  one  time  procedure  is  seldom 
successful.  The  allocation  of  processes  in  the  data 
flow  diagrams  are  either  done  according  to  the  target 
system  at  the  very  beginning  or  are  not  used  at  all 
when  the  final  software  processes  are  allocated  to  the 
hardware.  This  practice  is  partly  confirmed  by  Post 
(4],  Chen  and  Steimle  (9)  illustrate  the  drastic 
differences  in  the  software  design  that  performs  the 
same  application  function  but  delivers  different 
performance  characteristics.  A  major  portion  of  the 
software  design  is  unaccounted  for  in  the  solution. 
The  unaccounted  fr  riftware  in  the  design  is  the 
software  that  effectively  links  the  hardware 
resources  and  operating  system  resources  to  the 
applications  software. 


Figure  3.  System  Layers 
The  binding  abject*  art  net  unlike  the  transaction  support 
systems,  provided  by  UNI  VAC  or  MM,  that  address  non- 
transaction  oriented  activities  such  aa  FaullTolcrant 
communications, 


The  second  assumption  was  that  the  software 
designer  does  not  need  to  understand  the  hardware 
being  used  in  the  system.  In  order  to  achieve 
performance,  unique  hardware  and  operating  system 
control  structures  arc  used  in  the  the  final  solution. 
These  structures  control  parallelism,  manage 
storage,  address  data  integrity  and  other  key  system 
characteristics.  Karp  (8)  and  Burger  (5]  elaborate  on 
this  point.  This  discussion  on  the  explicit  control  of 
parallel  activities  and  storage  management  can  be 
defined  as  a  binding  effort  to  mate  the  application  to 
the  chosen  hardware. 

Figure  3  illustrates  how  the  software  in  a  system 
can  be  seen  as  a  layered  collection  of  elements.  At  the 
heart  of  this  collection  is  the  operating  system  which 
mates  all  the  software  to  the  hardware.  Next  come 
the  languages,  linkers,  IPCs,  and  system  con¬ 
figuration  files  that  not  only  translate  application 
program  source  code  to  executable  code,  but  also 
define  the  profile  of  the  application  and  bind  the 
application  to  the  services  and  facilities  provided  by 
the  operating  system.  The  application  gains  the 
services  of  the  CPU  and  1/0  by  manipulating  these 
services.  The  next  layer  is  the  binding  objects  layer. 
The  outer  layer  of  this  collection  of  elements  is  the 
functional  object0.  The  functional  objects  must  follow 
the  interface  rules  to  the  inner  layer  while  satisfying 
the  functional  requirements  of  the  application. 
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This  picture  is  hot  new  and  there  is  an  existing 
model  for  this  concept  in  the  form  of  transaction 
services.  The  transaction  services  of  IBM,  UNISYS, 
and  other  computer  vendors  allow  multiple 
applications  to  he  developed  without  recreating  the 
software  that  links  the  primary  mission  applications 
software  to  the  hardware  and  operating  system 
services.  This  shell  can  he  extremely  large  in  terms 
of  the  total  software  effort  depending  on  the  system 
characteristics. 


Examples  include  the  transaction  processing 
paradigm  provided  by  Sperry  11*8  1100  and  C1CS 
supported  by  IBM.  The  binding  objects  are  transac¬ 
tion  processing  support  software  Sums  provided  by 
the  vendor.  The  transaction  programs  are  discrete 
programs  provided  by  the  user  that  satisfy  the 
functional  requirements  of  the  application.  In  the 
case  of  Sherry,  these  programs  must  be  coded 
according  to  a  style  defined  by  11*8 1 100  and  follow 
the  interface  rules  to  TPS  1100.  The  same  require¬ 
ments  are  true  for  the  C1CS  supported  by  IBM. 

The  issue  is  thut  if  a  software  IC  is  to  achieve 
reusability  then  that  software  IC  should  be  purely 
functional  in  nature  and  not  contain  any  "glue”  to 
bind  it  to  hardware  or  operating  system  services.  In 
other  words,  the  software  IC  should  be  separable  from 
the  architecture  of  each  application.  In  addition,  the 
success  of  a  software  IC”  is  based  on  its  firm,  fixed, 
accepted  interface  definitions  which  effectively 
translate  to  the  architecture  of  that  software  IC.  The 
binding  objects  in  Figure  3  must  present  a  standard, 
well  defined,  well  accepted  interface  to  the  functional 
objects. 

The  step  taken  to  design  this  system  is  a 
pragmatic  one.  First,  the  architecture  of  the  system 
is  laid  out  to  contain  all  the  characteristics  of  a 
successful  reusable  system.  Table  111  lists  the  archi¬ 
tecture  components  of  the  reusable  high  performance 
communication  system  according  to  the  required 
characteristics.  Structured  analysis,  as  well  as  object 
oriented  programming  technique,  is  used  to  build  the 
functional  objects  and  the  binding  objects  as 
illustrated  by  Chen  and  Sutton  (3). 


Table  HI.  Reusable  High  Performance 
Communication  System 
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HIN1HNC  ARCHITECTURE 

Within  UNIX  a  high  performance  application 
with  asynchronous  inputs  is  made  up  of  UNIX 
processes  and  device  drivers.  These  UNIX  processes 
and  device  drivers  can  be  distributed  into  various 
hardware. 

The  UNIX  processes  are  further  divided  into  input 
processes  and  principle  processes.  Each  input  process 
is  dedicated  to  an  input  Sufficient  input  processes 
are  created  so  that  there  is  always  a  free  input 
process  available  when  the  device  driver  receives  an 
input  from  any  device.  The  UNIX  processes  com¬ 
municate  to  the  device  driver  through  file  I/O.  The 
UNIX  processes  synchronise  with  each  other  through 
shared  memory,  11*0,  disk  files,  and  interprocessor 
1PC.  The  UNIX  processes  are  distributed  across 
several  loosely  coupled  processors. 

Each  UNIX  process  must  be  programmed 
according  to  a  program  paradigm  which  is  compatible 
to  the  binding  objects  and  the  binding  architecture. 
Each  UNIX  process  in  this  application  is  made  of  the 
following  components: 

Rinding  objects: 

•  Main  program 

This  is  the  software  that  ties  all  procedures 
together  to  form  a  UNIX  process. 

•  System  Access  Packages  (SAI’s) 

This  is  a  procedure  interface  to  procedures  in  a 
different  process. 

Functional  objects: 

These  are  the  software  packages  that  directly 

relate  to  some  application  functional  require¬ 
ments. 
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Binding  objects  are  those  software  items  that  lie 
nil  pieces  or  the  application  together  but  do  not 
directly  support  application  functional  requirements. 

•  Main  program 

The  main  program  is  the  one  single  part  that 
ties  all  the  packages  together  when  the 
subsystem  is  used  as  a  process.  This  program 
is  individually  developed  for  each  process. 

•  System  Access  Packages  (SAi’s) 

The  system  access  point  is  defined  as  a 
software  package  which  is  independently 
developed  to  connect  functional  objects  in 
different  UNIX  processes.  Instead  of  inter¬ 
facing  directly,  through  IPC  or  shared 
memory,  the  functional  objects  interface  with 
the  system  access  pointts). 

This  concept  is  similar  to  the  remote  procedure 
call  elaborated  on  by  Wilber  and  Hacarissc  (2). 
A  SAP  contains  three  main  parts: 

1.  Server  interface  package  -  A  package 
specification. 

2.  Client  interface  package  -  A  package 
specification. 

3.  Body  objects  -  Several  body  objects  are 
required  for  each  SAP.  There  is  one 
package  body  for  each  interface. 

FUNCTIONAL  OBJKCTS 

Functional  objects  are  those  software  items  that 
are  directly  related  to  the  functional  requirements  of 
the  application.  The  functional  requirements  of  a 
data  communication  system  can  be  partitioned  into 
the  following  functions  according  to  the  ISO  7  layer 
model.  The  Data  transportation  functions  are: 

•  Application 

•  Presentation 

•  Session 

•  Transport 

•  Network 

•  Link 

•  Physical 

The  Management  functions  are: 

•  Monitor  and  record 

•  Network  management 


Through  standardisation,  each  of  component  of 
this  model  is  reusable  in  different  applications. 
There  are  ‘  lowevcr,  many  protocols.  Therefore,  each 
appln  Auwrt  that  wants  to  incorporate  reusable  code 
must  bt'.nd  implementations  of  the  protocols. 

A  high  performance  communication  software 
system  can  be  made  up  of  the  following  two  groups  of 
UNIX  processes: 

Data  transport: 

•  Front-end  network  process 

•  Back-end  network  process 

Management  entity: 

•  Monitoring  and  recording  process 

•  Network  management  process 


The  Data  transport  subsystems  have  the  following 
characteristics: 

•  They  implement  parts  or  all  of  the  ISO  7  layer 
functions  above  level  2  protocol.  The  two  lower 
level  protocols  are  implemented  as  UNIX 
device  drivers. 

•  They  transport  data  from  one  connection  to 
another  connection.  The  sub-system  usually 
consists  of  a  protocol  part  and  a  set  of  tables 
describing  each  connection. 

•  They  can  easily  be  replicated  and  distributed 
over  many  computer  processors. 

The  Management  subsystems  have  the  following 
characteristics: 

•  They  communicate  with  all  7  layers  of  the  ISO 
model. 

•  They  either  provide  a  centralised  control  for 
the  whole  communication  system,  or  provide  a 
centralised  repository  for  the  whole 
communication  system. 

•  They  ccn  be  distributed  over  many  processors 
only  in  a  hierarchical  manner. 

In  the  implementation  of  a  customised  communi¬ 
cation  system,  these  subsystems  are  combined,  or 
split  into  a  number  of  processes,  and  distributed  on 
the  selected  hardware  (computers)  according  to  the 
operating  system  characteristics  and  the  application 
traffic  flow  to  obtain  the  best  performance  for  the 
hardware  chosen  to  host  the  communication  system. 
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Ada  is  mandated  by  the  contract  for  this  data 
communication  system,  its  package  features  enable 
an  elegant  implementation  of  each  SAP,  shown  in 
Figure  4.  Ada  package  specification  provides  a  nice 
Ada  facade  for  each  SAP  that  can  be  independently 
compiled.  The  features  provided  by  Ada  are  severally 
hampered  because  each  Ada  linked  output  is 
implemented  as  a  single  UNIX  process.  The  very 
large  load  module  generated  by  Ada  is  also  an  issue  of 
concern. 


•  • 
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SVSTSM  ACCESS  PACKAGES  (SAP*) 

Figure  4.  System  Access  Package  (SAP) 
the  SAP  Interface*  the  functional  application  to  the 
upc ratine  *y*Um  and  hardware  environment 
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All  the  functional  objects  must  be  constructed 
according  to  compatible  program  paradigms  for  this 
clast  of  reusable  system.  This  programming  style  is 
developed  in  the  traditional  transaction  processing 
system  shown  in  Figure  5. 
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Figure  5.  Compatible  Program  Puradigm  Loop 


Kach  transaction  program  is  made  up  of  one  or 
more  transactions.  The  transaction  program  accepts 
asynchronous  input  only  In  one  predetermined 
location  in  the  program.  Each  transaction  is  driven 
by  one  unique  input  The  transaction  processes  the 
input,  updates  related  data  base  information,  stores 
intermediate  results  or  generates  output,  then  loops 
hack  and  waits  for  the  next  input  The  programming 
style  can  be  illustrated  by  the  following  example 
where  a  free  style  program  Is  transformed  to  a 
transaction  program: 


I. 

Head  A 

.•asynchronous  input 

•* 

KcadH 

••asynchronous  input 

3. 

C=:A+H  ...... 

asynchronous  inputs 

4. 

Write  C 

5. 

U>op 

A  transaction  program  to  accomplish  the  same 
requirement  looks  like  the  following.  The  sequence 
in  each  column  is  a  transaction. 


1. 

Head  A  or  I) 

••  Home  position  wail  for 
inputs 

2. 

irA 

Else 

3. 

If  Bison  queue 

3.  If  A  is  on  the  queue 

then 

then 

getB- 

get  A- 

Synchronous 

Synchronous 

input 

input 

C:=A+B 

C:=A+B 

write  C 

write  C 

Else 

Else 

put  A  on  queue  put  Bon  queue 

exit  or  loop 

exitor  loop 

Synchronous  inputs  ore  inputs  that  the  trans¬ 
action  can  get  on  demand.  These  inputs  are  stored  in 
shared  memory  or  in  local  disk. 
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CONCLUSION 

Our  attempt  io  build  a  high  performance 
communication  system  incorporating  reusability  was 
marginally  successful.  We  demonstrated  that  when 
mqjor  functions  are  rearranged,  a  specific  level  of 
performance  can  be  achieved.  We  showed  that 
Functional  objects  are  reusable  and  portable;  that 
Binding  objects  are  reusable  but  not  easily  portable 
to  different  operating  systems;  and  the  use  of  an 
enumeration  type  makes  the  addition  of  a  new 
function  difficult. 

The  ECI  approach  to  reusability  was  attempted  on 
a  high  performance  comm  system  with  approxi¬ 
mately  100K  lines  of  Ada  code.  Although  the 
program  did  not  specifically  identify  reusability 
requirements,  we  did  include  an  effort  to  identify 
characteristics  which  supported  reusability. 

The  design  required  several  physical  allocation 
changes  in  the  development  cycle  to  achieve  the  best 
performance  and  reliability  goals.  These  changes 
were  accomplished  with  no  changes  in  Functional 
objects,  litis  provided  confidence  that  the  function 
aspects  could  be  ported  to  different  system  hardware 
platforms  to  combine  with  new  Binding  objects  to 
carry  out  the  same  application.  This  approach  to 
reusability  accommodates  the  different  architecture 
requirements  to  achieve  the  best  performance  and 
reliability  in  difficult  hardware  platforms. 

In  summary,  this  novel  approach  to  reusability  is 
based  on  acknowledging  that  systems  consist  of  func¬ 
tional  and  architecture  dependent  code.  Given  this 
assumption,  the  design  process  includes  separating 
functional  code  from  architecture  code  early  in  the 
effort  and  defining  a  binding  mechanism  that  uses 
existing  services,  the  SAP  and  the  mainline. 

We  recognise  lliat  our  paradigm  needs  extensive 
refinement  and  expansion  to  provide  the  level  of 
reusability  needed  in  current  Ado  applications.  ECI 
expects  to  continue  its  research  into  the  applications 
of  reusability  in  three  existing  programs,  and  will 
attempt  to  expand  its  present  data  base  to  other 
systems  through  several  mechanisms  now  under 
active  research. 
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Abstract 

High-Impact  reuse  Is  achieved  by  focusing  on  specific 
Application  Domains.  A  Software  Component  Reuse 
Library  System  must  support  domain  modeling  os  won  as 
repository  management  features.  The  RLF  project 
addresses  both  of  these  areas.  Repository  managemoni 
capabilities  including  retrieval,  classification,  insertion 
and  qualification  of  components  are  alt  provided.  Domain 
modeling  is  ochievod  through  Knowledge  representation 
components  that  wore  developed  tn  Ada  using  an  Ada 
perspective.  The  domain  model  provides  an  effective 
and  powerful  interface  to  the  Gbrary.  An  evolutionary 
approach  has  enabled  the  production  of  a  family  of 
librarian  applications  of  varying  functionality  and  polnt-of- 
view.  Ada  features,  such  as  generics  and  exception 
handing,  and  Ada  design  principles,  such  as  data 
abstraction,  are  used  to  construct  systems  that 
incorporate  traditional  A!  functionality  whito  providing 
enhanced  systom  maintainability  and  evolvabifity. 


1.  Introduction. 

This  paper  describes  tho  accomplishments  and  experi¬ 
ences  of  tho  Reusability  Ubrary  Framework  (RLF) 
project'  being  performed  at  the  Paofi  Research  Center. 
The  RLF  project,  as  part  of  the  STARS  (Software 
Technology  for  Adaptable  and  Reliable  Systems) 
Foundations  program,  was  proposed,  designed  and  is 
being  implemented  to  meet  several  goals. 

Our  primary  focus  is  the  development  of  framework  tech¬ 
nology  to  support  the  creation  of  software  reuse  libraries 
(or  repositories)  that  provide  for  an  intetligently-guidod 
search  through  a  library  of  software  components,  and 
more  generally,  a  knowledge-based  approach  to  the 
management  of  software  artifacts  that  apply  to  a  particu¬ 
lar  application  domain.  To  achieve  this  primary  goal,  wo 
developed  reusable,  stand-alone  Ada  subsystems  to  pro¬ 
vide  the  necessary  knowledge-based  technology.  These 
components  form  the  underlying  structure  upon  which  li¬ 
brarian  applications  are  constructed.  As  a  demonstration 

*  Th«  work  dtiabtd  h«t«in  wu  luntf«d  by  STARS  Foundations  contract 
numbar  N0OOU-8S-C-2O52,  admin&srtd  by  tht  Naval  Research 
Laboratory. 


that  wo  have  produced  tho  required  toots  and  capabili¬ 
ties,  wo  are  creating  a  proof-of-concepl  Ada  component 
library  hosted  on  the  framework. 

Our  approach  to  meeting  these  goals  was  first  to  exam¬ 
ine  alternate  approaches  to  knowledge  representation  in 
the  literature  as  well  as  In  Artificial  Intelligence  (Al) 
projects  conducted  at  Unisys.  We  identified  two  comple¬ 
mentary  technologies  from  this  search  and  developed 
Ada  designs  end  implementations  that  provide  a  powerful 
technological  base  on  which  to  host  librarian  applications. 
AdaKNET  (Ada  Knowledge  NETwork)  and  AdaTAU 
(where  TAU  Is  an  acronym  denoting  the  phrase 
Think— Ask— Update)  resulted  from  this  analysis. 

AdaKNET  enables  the  creation  of  structured  inheritance 
networks  (sometimes  called  semantic  notworks)  which 
ore  used  to  model  the  structural  component  taxonomies 
that  evolve  whenever  leng-lived  and  large  scale  software 
development  takes  place  In  particular  application  do¬ 
mains.  AdaTAU  provides  a  rule-base  formalism  used  to 
conduct  Inforendng  over  particular  knowledge  networks. 
In  particular,  AdaTAU  provides  expert  assistance  for  the 
novice  library  user  In  browsing,  searching  and  installing 
software  components  in  the  repository. 

Both  of  these  components  may  be  Integrated  into  hybrid 
knowledge  representation  systems  and  to  demonstrate 
this  we  developed  a  knowledge-based  Ada  unit  test  as¬ 
sistant  called  Gadfly.  This  system  uses  a  coordinated 
knowledge  base  about  Ada  units  and  testing  methodolo¬ 
gies  to  generate  unit  test  plans.  These  plans  are  based 
on  a  parsed  representation  of  Individual  Ada  components 
and  a  rule-base-guided  dialogue  with  tho  user.  Such  a 
dialogue  Is  designed  to  probe  for  relevant  assumptions 
regarding  the  construction  and  intended  use  of  the  unit. 
Gadfly's  design  allows  it  to  function  as  either  a  stand¬ 
alone  test  plan  assistant,  or  as  a  testing/quality  assur¬ 
ance  module  as  part  of  a  complete  librarian  application. 

The  interconnection  of  these  components  and  their  Inte¬ 
gration  into  librarian  systems  of  varying  strength  and 
functionality  is  illustrated  in  Figure  1.  At  the  top  of  this  di¬ 
agram,  the  qualifying  librarian  denotes  our  final  delivered 
system  which  Includes  Gadfly  as  an  Important  module 
used  to  validate  library  components  that  are  offered  for 
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inclusion  In  the  library.  This  system  should  be  viewed  as 
a  demonstrable  prototype  of  the  representational  and 
managerial  power  that  we  provido.  and  the  Integrabliity  of 
the  subsystems  that  we  have  developed.  Leading  up  to 
this  Inclusive  prototype,  we  have  developed  Intelligent  II* 
brarian  systems  of  smaller  size  and  functionality  aimed  at 
exploiting  various  aspects  of  our  underlying  technologies. 
Theso  systems  all  support  the  basic  search,  retrieval  and 
insenion  of  software  components  in  library  settings  based 
on  domain-specific  knowledge  stored  in  knowledge 
bases  encoded  by  AdaKNET  and  AdaTAU. 

Section  2  presonts  a  discussion  of  the  power  and  useful¬ 
ness  of  constructing  libraries  based  on  a  domain  model 
with  our  prototype  domain  of  Ada  benchmarks  providing 
Illustrations.  Major  components  of  the  project  shown  in 
Figure  1  are  described  more  fully  in  sections  3  and  4  of 
this  paper.  The  knowledge  base  components  and  Gadfly 
are  themsolvos  tho  subject  of  a  papor  delivered  at  tho 
AIOA  •  68  conference  (Wanes]  and  the  interested  roader  is 
encouraged  to  consult  this  paper  to  expand  upon  tho  rel¬ 
atively  high  level  view  of  the  knowledge  base  compo¬ 
nents  and  Gadfly  that  is  given  here.  We  closo  the  paper 
with  a  section  describing  some  ol  our  Ada  experiences 
and  lessons-learned  and  a  final  sedion  that  summarizes 
project  results  and  presents  some  of  the  conclusions  that 
we  have  reached  as  a  result  of  working  on  tha  project. 

2.  Domain-Specific  Libraries  -  An  Example 

A  major  goal  of  Ada  developers  is  to  reduce  code  devel¬ 
opment  time  by  the  use  of  reusable  code.  One  difficulty 
in  code  reuse  has  always  been  locating  and  seleding  ap¬ 
propriate  existing  code.  Another  has  been  in  making  use 
of  code  which  may  have  been  written  for  a  quite  different 
purpose,  with  different  assumptions  and  needs. 
Modifications  must  be  made  with  care,  without  inadvert¬ 


ently  violating  somo  assumptions  and  therefore  introduc¬ 
ing  errors.  Tho  purpose  of  tho  Reusability  Library 
Framework  is  to  provide  tho  usor  with  intelligent  assis¬ 
tance  in  inserting,  retrieving  and  using  Ada  code  modules 
located  in  a  sottwaro  parts  library. 

In  order  for  rouse  technology  to  succood  and  permit  tho 
large  scale  productivity  increases  that  wore  forsoen  back 
in  the  oarly  days  of  software  engineering  (Mcirre),  such 
technology  must  go  beyond  tho  basic  notions  of  subrou¬ 
tine  libraries,  directory-based  repositories  and  simple 
software  catalogs.  A  domain  modol  approach  to  rouso  li¬ 
braries  has  tho  potential  to  provide  tor  significant  produc¬ 
tivity  boosts.  This  assertion  is  supported  by  tho  following 
evidence. 

Collections  of  modules  that  have  been  extensively  re¬ 
used  such  as  tho  well-known  Fortran  mathematics  and 
statistics  libraries  were  organized  around  particular, 
clearly  understood  domains.  Moreovor  the  reusability  of 
a  particular  component  is  itself  a  relative  property  of  its 
place  within  an  application  domain.  The  design  of  a  reus¬ 
able  component  has  been  compared  to  a  kind  ol  maiket 
analysis  to  determine  important  properties  and  features 
of  a  component,  along  with  performance  requirements 
(MccaM).  A  repository  must  provide  explicit  support  to 
application  developers  working  in  specific  application 
areas.  Each  such  applications  area  will  require  a  special¬ 
ized  set  of  capabilities  that  are  themselves  highly  reus¬ 
able  [B«ui3].  Domain-specificity  also  enlarges  the  granu¬ 
larity  of  reuse,  supporting  systom  composition  tn  torms  of 
subsystems  tailored  according  to  the  requirements  of 
new  or  modified  applications. 

The  representational  capabilities  required  of  a  domain- 
oriented  reuse  system  go  beyond  those  provided  by  a 
project  database,  but  are  less  than  thoso  required  of  a 
complete  CASE  (Computer-Aided  Software  Engineering) 
environment.  Future  CASE  environments  must  be  con¬ 
structed  to  support  large  scale  reuse  efforts  and  so  do¬ 
main  modelling  must  be  integrated  into  future  CASE  sys¬ 
tems.  Thus  a  reuse  library  system  must  support  system 
develc~ment  and  not  merely  component  retrievals. 
Researchers  have  already  pointed  out  the  importance  of 
domain-specific  knowledge  in  the  software  development 
process  [B«r»«5j.  A  modem  library  systom  must  also 
support  alternative  technologies  for  systom  development; 
for  example,  a  constructive  approach  through  component 
composition  and  a  generative  approach  through  compo¬ 
nent  specifications  (slmo«). 

To  date,  there  Is  no  widely  accepted  'Dowey-decimat* 
classification  system  for  software  libraries.  There  are 
certainly  no  standard  hierarchical  systems,  and  no  stan¬ 
dard  indexing  schemes  supporting  retrieval  from  such 
storage  hierarchies.  The  RLF  approach  supports  the  ex¬ 
perimentation  with  many  different  classification  schemes, 
each  tailored  according  to  particular  application  domains. 
The  RLF  also  supports  tailored  search  and  retrieval  ca- 
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pabiliiies  depending  on  (he  domain  as  woll  as  s  user's 
skill  level  and  personal  preferences.  By  contrast,  other 
published  approaches  to  library  management  are  (undo* 
mentally  vyeakor. 

Other  projects  have  chosen  to  focus  on  either  a  hiorarchi- 
cal  approach  or  a  data  base  approach.  Hierarchies  pro¬ 
vide  a  rfgid  classification  schome  which  enable  compo¬ 
nent  retrievals  based  on  searches  of  the  hierarchy.  The 
database  approach  requires  the  usor  to  construct  data¬ 
base  queries  which  may  or  may  not  produce  a  compo¬ 
nent  o<  the  kind  being  sought.  Recent  projects  havo 
begun  to  experiment  with  limited  hybrid  systems  that 
combine  the  two  approaches  (Prt«e7)  |8urie7].  In  any 
case,  these  approaches  are  timiicd  by  their  support  for  a 
single,  fixed  taxonomic  model,  and  their  presentation  of  a 
single  user  interface  supporting  only  one  category  of  B* 
brary  user. 

The  RIF  framework  provides  support  for  boih  dynamic 
and  experimental  classification  systems  as  woll  ns  multi¬ 
ple  classes  of  users.  By  using  knowledge-base  compo¬ 
nents,  the  RLF  is  able  to  support  a  separate,  declarative 
domain  model  with  powerful  and  adaptive  taxonomic 
power  along  with  tailorable  search,  retrieval  and  compo¬ 
sitional  capabilities.  Tho  domain  model  exists  indepen¬ 
dently  of  the  repository  of  components  and  expands  upon 
the  services  provided  by  competing  library  organizations. 

The  RLF  framework  onables  tho  definition  and  usq  ol  tax¬ 
onomies  for  classifying  Ada  cooe  and  code-related 
Information.  This  framowork  uses  AdaKNET  to  prov.de  a 
structure  into  which  specific  Ada  components  can  be 
inserted.  The  framowork  supports  multiple  orthogonal 
taxonomies;  thus  codo  can  be  classified  by  function,  by 
structure,  and  by  any  other  rolovant  characteristics.  Tho 
current  project  will  creato  a  subset  of  a  complete  tbrnry 
instance,  concentrating  on  tho  domain  of  Ada  bench¬ 
marks. 

In  addition  to  tho  generic  framowork,  tho  Library  must 
have  content.  In  order  to  domonstrato  tho  feasibility  of 
the  framowork.  the  RLF  project  wit!  populate  It  with 
benchmark  routines  drawn  from  sovoral  sources.  Theso 
sources  include  the  Ada  Compiler  Evaluation  Capability 
(ACEC)  suite  developed  by  Softech.  the  Performance 
Issues  Working  Group  (PIWG)  suite  developed  by  tho 
ACM  Special  Intorest  Group  on  Ada  (SIGAda),  and  tho 
Hughes  Aircraft  Company  Ada  Benchmark  Suite. 

Organizing  code  modules  into  appropriate  taxonomies 
facilitates  their  retrieval  and  use.  However,  rouse  is 
aided  substantially  if  the  usor  Is  also  provided  less  formal 
information  about  the  domain  or  tho  codo.  This  kind  of 
Information  can  include  guidance  about  the  most  appro¬ 
priate  code,  indications  of  other  needed  modules,  etc.  It 
represents  tho  kinds  of  rules  of  thumb  that  experts  in  a 
particular  area  develop,  to  provide  shortcuts  and  improve 
efficiency.  This  compilation  of  expert  knowledge  will  be 


represented  in  the  Reusability  Library  Framework  os 
AdaTAU  roles. 

Figure  2  illustrates  a  small  fragment  of  tho  Ada  bench¬ 
mark  taxonomy  that  is  being  developed  as  part  of  this 
project.  This  fragment  modols  the  architectural  decom¬ 
position  of  benchmark  programs  as  welt  as  the  set  of  Ada 
features  that  are  of  Interest  to  benchmark  creators.  An 
Individual  benchmark  component  ts  categorized  accord¬ 
ing  to  this  classifying  framework.  Such  an  individual  in¬ 
herits  properties  {attributes}  from  alt  ol  tho  categories  of 
which  it  is  a  member. 

Tho  figure  shows  that  tho  code  category  is  broken  down 
into  timer  and  benchmark  program  subcategonos. 
Benchmark  programs  measure  Ada  features.  This  rela¬ 
tionship  is  indicated  by  tho  labeled  arrow  botween  tho 
two  catogorios.  Any  number  ol  features  can  bo  mea¬ 
sured  by  a  benchmark  and  so  tho  benchmark  program 
category  shows  an  unlimited  range  for  tho  number  of 
measured  features.  The  figure  also  shows  that  bench¬ 
marks  programs  are  broken  down  along  suite  member¬ 
ship  as  welt  as  feature  measurement.  In  particular,  an 
ACEC  feature  benchmark  must  be  equipped  with  a  par¬ 
ticular  timer  module  in  order  that  the  benchmark  be  exe¬ 
cuted  property.  Furthermore,  timer  programs  are  them- 
selves  delineated  according  to  the  Ada  ron-timo  system 
being  ufSzed. 

As  can  be  seen,  the  web  ot  relationships  and  dependen¬ 
cies  can  bccomo  complex  even  in  a  narrow  portion  of  a 
narrow  domain.  Tho  RLF  framowark  not  only  supports 
the  capturing  of  this  information,  but  through  integratod 
role  bases  it  permits  an  expert's  vlow  ot  tho  taxonomy  bo 
given  to  oven  novice  users.  For  example,  tho  user  can 
be  aided  in  browsing  tho  domain  model  as  woll  as  in  con¬ 
figuring  an  application  (in  this  caso  assembling  meaning¬ 
ful  benchmark  programs).  Exactly  the  right  timer  is  re¬ 
trieved  that  matches  tho  selected  ACEC  foaturo  bench¬ 
mark  which  measures  tho  dosired  feature  within  tho  de¬ 
sired  Ada  ron-timo  platform. 


3.  Knowledge  Repiesentatlon  Systems 

Underlying  knowledge  representation  systoms  are  critical 
to  tho  building  ol  domain-specific  libraries.  Thus,  such 
systems  are  the  underpinnings  of  tho  RLF  project. 
AdaKNET  and  AdaTAU  are  derived  from  Unisys  systoms 
that  wero  developed  in  Prolog  and  which  have  succes¬ 
sively  been  applied  to  various  problem  domains.  Theso 
systems  wero  themselves  designed  from  welt-accepted 
knowledge  representation  and  processing  methodologies 
as  developed  In  the  Al  literature.  However,  our  approach 
was  not  to  capture  the  style  or  approach  of  traditional  Al 
systems  implemented  in  Lisp  or  Prolog,  or  to  create  largo 
Ada  systems  that  emulate  significant  portions  ol  Lisp 
and/or  Prolog,  but  rather  to  analyze  the  objects  and  op¬ 
erations  provided  by  proven  Al  subsystems  and  to  rede- 
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sign  (engineer)  and  Implement  them  from  an  Ada  per¬ 
spective.  In  particular,  we  examined  candidate  systems 
with  an  eye  toward  exploiting  the  strengths  c(  the  Ada 
language  when  achieving  actual  implementations.  We 
tried  to  view  various  knowledge  representation  schemes 
in  terms  o!  the  services  they  provide  and  the  underlying 
structures  used  to  enable  these  services.  In  short,  we 
took  an  abstract  data  type  point-ol-view. 

This  approach  naturally  led  to  a  convenient  and  important 
separation  of  the  procedural  and  declarative  knowledge 
that  together  permit  knowledge-based  processing  to 
occur.  The  content  ol  domain-specific  knowledge  basos 
is  defined  through  the  use  of  specification  languages. 
Knowledge-base  processing  occurs  via  the  execution  of 
operations  defined  In  the  knowledge-base  components. 
Furthermore,  using  an  Ada  perspective  led  to  a  layered 
implementation  plan  that  resulted  in  increasing  levels  of 
functionality  and  semantic  checking  being  built  upon 
lower,  and  more  primitive  layers.  The  following  subsec¬ 
tions  briefly  discuss  the  individual  subsystems  and  their 
hybridization.  Gadfly  is  discussed  as  one  panicular  ex¬ 
ample  of  hybridization.  We  also  illustrate  the  specifica¬ 
tion  languages  with  £  couple  of  examples. 


AdaKNET 

Figure  3  shows  a  skoletal  description  of  the  design  of  the 
AdaKNET  system.  AdaKNET  is  based  on  a  proprietary 
system  developed  at  the  Paoli  Research  Centor  called 
KNET  [FrtwM).  KNET  Is  itself  derived  from  a  well-known 
knowledge  representation  system  called  KL-ONE 
(Bradi}.  KNET  has  been  successfully  applied  to  the  area 
of  (computer)  system  configuration.  AdaKNET  (and 
KNET)  supports  the  management  of  two  basic  relation¬ 
ships  between  objects  and  classes  of  objects:  specializa¬ 
tion  and  aggregation.  Specialization  captures  the  sort  of 
knowledge  that  one  thing,  or  category  of  things,  Is  a  spe¬ 
cial  case  (or  kind)  of  another  thing.  For  example,  the  cat¬ 
egory  of  Ada  subprograms  includes  both  procedures  and 
functions,  while  the  category  of  Ada  compilation  units  in¬ 
cludes  both  packages  and  subprograms.  Aggregation 
captures  the  fact  that  one  thing  or  category  of  things  is 
partially  defined  by  its  constituents  or  Its  properties 
(sometimes  called  attributes).  For  example,  an  Ada 
package  specification  is  defined  by  its  name,  the  types  it 
exports,  and  the  operations  it  exports.  Also,  an  Ada  soft¬ 
ware  system  is  defined  in  terms  of  its  subsystems  which 
are  defined  by  the  constituent  packages  of  the  sub¬ 
systems. 
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AdaKNETs  representational  power  comos  (ram  its  mod* 
•Hng  ol  these  two  relationships,  and  thair  coordination 
through  the  use  o(  inheritance.  Inheritance  S'.,  the  capabil¬ 
ity  that  a  subcategory  ol  a  category  automatically  Inherits 
alt  ol  the  attributes  ol  the  parent  category  (called  super 
categories}.  The  attributes  ol  a  subcategory  may  refine 
those  ol  a  parent  category,  but  may  never  contradict 
them.  However,  a  subcategory  can  admit  entirely  new 
attributes  not  defined  (or  the  parent.  This  Inheritance  is 
not  local  (one  level  only)  but  completely  transitive  whore 
attributes  ol  far-away  parents  are  available  at  any  node. 
AdaKNET  rigorously  enforces  the  sort  ol  specialization 
semantics  required  by  such  a  system,  where  violations 
give  rise  to  Ada  exceptions. 

We  have  experimented  with  various  forms  ol  inheritance 
and  recently  have  Implemented  a  form  ol  multiple  inherit¬ 
ance  where  a  subcategory  ol  two  or  more  super  catego¬ 
ries  is  equipped  with  the  attributes  ol  all  super  categories. 
Multiple  Inheritance  permits  smaller  and  clearer  specifica¬ 
tions  ol  relationships  that  commonly  occur  in  a  software 
component  library.  For  example,  a  particular  benchmark 
program  can  simultaneously  be  a  kind  ol  feature  bench¬ 
mark  as  well  as  a  mber  ol  a  particular  benchmark 
suite.  Through  multiple  inheritance,  each  ol  these  bench¬ 
mark  categories  bestows  a  set  ol  attributes  that  must  be 
filled  by  particular  values.  The  knowledge  representation 
model  provided  by  AdaKNET  is  a  natural  extension  ol  a 
library  framework  taxonomic  model  where  subject  areas 
are  broken  down  through  extensive  specializations,  and 
where  sub-categories  within  a  specialization  are  distin¬ 
guished  by  different  feature  sets  (attributes). 

By  modeling  information  independently  from  the  applica- 
dons  which  are  written  to  make  use  of  this  knowledge. 


the  information  can  be  reused  in  multiple  applications. 
For  example,  the  Ada  unit  model  defined  to  serve  the 
Gadfly  application  is  usable  as  is  within  any  ol  the  librari¬ 
an  applications.  The  Information  Itself  is  available  in 
ASCII  text  files  ol  SNDl  (Semantic  Network  Description 
Language)  specifications.  A  SNDL  example  describing  a 
small  part  ol  the  Ada  unit  model  is  shown  In  Figure  4. 
Seme  background  on  the  use  of  specification  languages 
within  AdaKNET  and  AdaTAU  is  given  later  in  this  sec¬ 
tion. 

AdaTAU 

Like  AdaKNET,  AdaTAU  is  based  on  a  Unisys-propri¬ 
etary  system  written  in  Prolog  called  TAU  (lor  Think,  Act, 
Updato).  TAU  was  Initially  developed  as  a  stand-alone 
rule-based  system  supporting  diagnosis  and  mainte¬ 
nance  ol  faulty  computer  equipment.  In  its  latest  form, 
TAU  has  been  incorporated  into  the  KSTAMP  system 
(Mrtuee)  where  it  (unctions  as  a  diagnostic  assistant  (of 
the  repair  ol  Postal  Service  mail  processing  equipment. 
KSTAMP  Is  also  an  example  ol  a  hybridized  system  that 
combines  two  different  knowledge  representation  sys¬ 
tems  (KNETandTAU). 

AdaTAU  processes  two  kinds  ol  information:  rules  and 
facts.  A  mle  is  a  statement  that  il  certain  (acts  are  true', 
then  other  lads  should  be  established  as  true.  A  simple 
rule  can  be  expressed  as: 

if  (pnranoterjl  is  type  integer)  chon 
(cest_caso_sot>_typQ  is 

intcgor_tosc_casc_3et) . 

This  example  shows  a  single  necossaiy  (act  (called  an 
antecedent)  and  a  single  resulting  fact  (catted  a  conse¬ 
quent).  In  AdaTAU.  there  may  be  multiple  antecedents 
and  consequents.  A  more  complex  kind  ol  rule  asserts 
particular  consequent  facts  depending  on  an  answer 
given  by  the  user  to  a  posed  question. 

Facts  are  simple  statements  which  are  collected  into  fact 
bases.  All  established  facts  are  placed  Into  a  fact  base 
which  is  accessible  for  the  purpose  ol  checking  the  appli¬ 
cability  ol  rules  (and  therefore  the  addition  ol  new  facts). 
The  state  ol  an  AdaTAU  inference  session  is  described 
by  the  current  collection  of  rules  as  we!!  as  the  currant 
collection  ol  known  facts.  In  its  simplest  form,  AdaTAU 
processes  an  initial  collection  ol  rules,  along  with  an  ini¬ 
tial  collection  of  fads  (perhaps  empty)  to  the  point  where 
no  new  facts  can  be  added  because  no  rules  are  left 
whose  antecedents  are  in  the  fact  base.  Typically,  after 
a  rule  is  applied  (or  “fired"),  it  is  marked  so  that  it  is  no 
longer  considered  for  firing.  The  end  result  of  an 
AdaTAU  execution  is  the  final  collection  of  facts  which  an 
application  that  Invokes  AdaTAU  can  process  in  an  appli¬ 
cation-specific  way. 
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concept;  Software  Component  (Thing)  is 
local  roles 

Cempencncjiame  (1..1)  of  Text? 

Description  (1..1)  of  Se£tware_Cempencnt_Deseripcien; 

Location  (1..1)  of  Cerpenent_Locaticn: 

Auxiliary_rec}uiro«J_co,T.psncncs  (0.. infinity)  of 
So  f twa  re„Cempenc nt ; 

Subunits  (0T. infinity)  of  Software  Subcomponent; 
end  local; 
one)  concept; 

concept  Ada  Compiler  Benchmark  (Software  Component)  is 
local  roles 

KcasurcdJFeatures  (1..1)  of  Ada  Featuros; 
end  local; 
end  concept; 

concept  ACECJJenehmark  (Ada  Compiler  Benchmark)  is 
local  roles 

Ccntrolj^easurcmenc^Ccmponenc  (1..1)  of  Sofcware_Component; 

InstrumcntjPackoge  Tl.-l)  of  Software_Cemponcnt;“ 

—  This  package  is  used  for  timing  the  control  and  the 

—  feature, 
end  local; 
end  concept; 

Figure  4.  SNOL  Fragment 


Figure  5  describes  layers  within  AdaTAU.  includmg  the 
provision  o(  a  ‘distributed'  version  o!  AdaTAU  based 
upon  a  simpler  centralized  scheme  (indicated  by  the 
Inner  two  layers).  Currently  the  centralized  form  of 
AdaTAU  supports  two  rule  types.  IRules  (Inference 
Rules)  fire  automatically  when  their  antecedents  are  de¬ 
termined  to  be  present  In  the  fact  base.  QRules 
(Question  Rules)  are  rules  which  do  not  directly  add  facts 
to  the  fact  base  but  rather  schedule  the  posing  of  ques¬ 
tions  to  the  user.  The  antecedents  of  a  QRule  must  be 
true  before  the  question  is  scheduled,  The  answer  given 
by  the  user  determines  which  collection  of  facts  is  added. 


The  distributed  form  of  AdaTAU  supports  the  use  of  mul¬ 
tiple  collections  of  rules,  collected  into  inference  bases, 
and  both  local  fact  bases  (to  record  Information  estab¬ 
lished  during  a  local  Inference  session)  and  global  fact 
bases  (to  record  Information  that  is  transferable  from  one 
Inference  session  to  another).  FRuIes  (Focus  Rules)  are 
provided  to  support  distributed  AdaTAU.  FRuIes  enable 
the  suspension  of  one  local  Inference  session  in  favor  c' 
another  one.  Distributed  AdaTAU  allows  the  partitioning 
of  Inferendng  cepability  into  localized  distributed  infer¬ 
ence  bases.  An  application-specific  partitioning  scheme 
supports  cooperative  focusing  to  the  most  appropriate  in¬ 
ference  base  (where  appropriateness  can  be  judged  from 
the  contents  of  the  global  and  local  fact  bases). 

The  actual  expression  of  rules  and  facts  is  accomplished 
by  a  RBDL  (Rule  Base  Definition  Language)  specification 


file.  A  RBDL  fragment  Is  given  in  Figure  6.  In  addition,  a 
RBDL  specification  file  must  declare  a  fact  base  schema 
definition  to  restrict  the  sorts  of  facts  that  can  be  Installed 
into  a  fact  base.  In  this  way,  AdaTAU  provides  a  typing 
mechanism  on  tacts  analogous  to  Ada's  own  typing 
mechanism. 
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fact  base  schema  Ada_Co£pilcr_Bcnc)mrk_Fact3  is 

accessjsode  :  cne_o£  (retrieve,  insert); 

benchmark  eurpose":  one  of  (feature,  composite,  suite,  new); 

suite_choTce  :  one_of  (ACEC,  PIWG,  help); 

suitejsember  :  one^of  (ACEC,  PXWG,  help,  unknown,  none); 

end  Ada_Compiler_Dcnchmark_Facts; 

question  Ask^Benchmar^Purpose  is 

text  :  (What  purpose  do  you  have  in  mind  for  the  benchmarks?); 
type  :  ene_o£; 
responses  7 

"test  specific  features  of  a  language"  ■> 

(benchmark  purpose,  feature); 

"test  a  mix  of  Zeatures  of  a  language"  ■> 

(benchmark  purpose,  composite) ; 

"choose  a  compiler  based  on  overall  performance"  ■> 
(bcnchm8rkjJurpose,  suite) ; 

end  question; 

qrule  Determlnu_Bcnchmatk_Purpose  is 

antecedent  :  (access  mode,  retrieve); 
question  :  Ask  Benchmark  Purpose; 
weight  ;  1;  “ 

justification  :  (Help  the  user  choose  the  next  level  according  to 
his  needs); 

end  qrule; 


Figures.  RBDL Fragment 


Forming  Hybrid  Systems  -  Gadfly 

In  designing  AdaKNET  snd  AdeTAU,  we  were  convinced 
that  although  these  systems  are  useful  separately,  they 
would  be  most  useful  within  the  software  reuse  library 
framework  when  they  are  combined  and  Integrated  with 
each  other.  We  discovered  that  the  forming  of  such  hy¬ 
brid  systems  is  not  an  oasy  task.  One  of  the  issues  we 
faced  is  the  degree  of  coupling  that  should  be  imposed 
on  the  two  systems— whether  the  subsystems  should  be 
tightly  or  loosely  coupled  with  one  anoth'er.  Another  is 
the  degree  to  which  application-specific  information  can 
be  migrated  to  the  knowledge  bases  maintained  by 
AdaKNET  and  AdaTAU,  and  kept  out  of  the  actual  Ada 
code  that  provides  the  application. 

Our  work  on  Gadfly,  the  Ada  unit  test  assistant,  resulted 
in  a  tightly  coupled  arrangement.  Certain  nodes  in  tho 
semantic  network  are  equipped  with  inference  bases  as 
provided  by  AdaTAU,  including  a  local  fact  base.  The 
Gadfly  application  itself  controls  how  these  inference 
bases  are  consulted  and  provides  a  communication 
mechanism  so  that  facts  can  be  transferred  into  and  out 
of  local  tact  bases. 

Gadfly  provides  a  stand-alone  Ada  unit  test  assistant. 
Briefly,  through  SNDL  specifications,  a  generic  Ada  unit 


I 


model  Is  defined  for  Ada  subprograms,  and  a  subset  ol 
Ada  type  semantics  is  Included  for  the  model  (for  exam¬ 
ple,  In  our  demonstrable  prototype  of  Gadfly,  semantics 
covering  Integer  and  file  parameters  are  included). 
Another  part  of  the  Gadfly/SNDL  specification  includes  a 
testing  model  to  break  down  testing  strategies  based  on 
Ada  types  and  testing  methodologies.  A  third  form  of 
knowledge  Is  recorded  in  multiple  Gadfly/RBDL  specifica¬ 
tion  files.  These  files  contain  test  case  heuristics  drawn 
from  ‘common  sense*  testing,  general  Ada  semantics 
and  particular  properties  of  individual  data  types. 

In  our  Gadfly  prototype,  we  provide  for  a  black  box  test¬ 
ing  strategy  broken  down  along  the  parameter  modes  of 
Ada,  as  well  as  the  supported  Ada  data  types.  We  com¬ 
plement  the  SNDL  portion  of  the  knowledge  base  with 
RBDL  specifications  of  the  sorts  of  questions  to  ask  the 
user  regarding  design  and  usage  assumptions  about  the 
unit  under  test.  These  rule  bases  are  located  at  testing 
category  nodes  within  the  SNDL-specified  semantic  net¬ 
work. 

When  Gadfly  is  executed,  the  source  code  for  an  Ada 
specification  is  parsed  to  yield  an  instantiated  form  of  the 
Ada  unit  model.  Gadfly  then  automatically  walks  the  user 
over  the  semantic  network  corresponding  to  this  individu¬ 
al  Ada  unit  and  generates  particular  facts  pertinent  to  the 
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totting  ot  (hit  Ada  unit.  The  test-related  (acts  deduced 
by  Gadfly  art  bated  on  tha  ratpontat  tha  user  gives  to 
tha  questions  baing  potad  at  wall  at  tha  particular  tatt¬ 
ing  modal  contained  within  GaeWy.  Finally,  another  net¬ 
work  wafc  it  conducted  during  which  ttorod  local  (acts 
art  converted  to  tett  cate  recommendations. 

Tha  integration  o  f  AdaKNET  and  AdaTAU  as  accom- 
pithed  in  Gadfly  was  our  first  experience  in  performing 
this  hybridization  and  our  approach  to  integration  remains 
vary  experimental.  For  example,  Gadfly  was  completed 
before  the  implementation  of  distributed  AdaTAU  was  it¬ 
self  comptoto.  In  particular,  Gadfly  does  not  make  use  of 
focus  rules  to  control  transfers  from  inference  bate  to  in¬ 
ference  bate,  but  rather  accomplish#*  such  transfers 
within  the  Gadfly  application  itself.  The  librarian  applica¬ 
tion#  take  advantage  of  the  carefully  arranged  focus 
twitches  provided  in  distributed  AdaTAU.  However,  like 
Gadfly,  particular  inference  bases  are  located  at  particu¬ 
lar  nodes  within  the  semantic  network. 

Knowhdg^Bt*  D—cripUon  Language 

Our  approach  to  defining  knowledge-base  processing 
components  was  to  view  them  as  abstract  data  types, 
and  layers  of  such  types.  In  defining  these  packages  we 
concentrated  on  the  necessary  operations  to  support  ap¬ 
portions  that  required  knowledge-based  processing, 
and  provided  the  underlying  objects  and  object  manage¬ 
ment  to  support  such  client  applications. 

The  RLF  project  was  conceived  and  executed  in  the  con¬ 
text  of  available  technology  that  supports  the  creation 
and  use  of  special  purpose  high  level  languages.  Such 
languages  permit  the  needs  of  specific  application  do¬ 
mains  to  be  expressed  in  terminology  appropriate  to  such 
domains.  In  our  case,  we  needed  a  way  to  specify  the 
contents  of  knowledge  bases  in  language  that  was  clear 
and  concise.  Furthermore,  such  descriptions  must  be 
processed  into  a  form  that  leads  to  installation  into  the 
data  structures  managed  by  AdaKNET  and  AdaTAU. 
The  abstract  data  type  (ADT)  approach  to  the  design  of 
knowledge  representation  systems  led  to  a  large  collec¬ 
tion  of  ADTs  with  complex  interactions.  Knowledge-Base 
specification  languages  hide  the  procedural  complexity  of 
the  ADTs  and  permit  easy-to-understand  instantiation  of 
knowledge  bases. 

The  use  of  such  specification  languages  hinges  on  the 
availability  of  support  for  their  design  and  Implementa¬ 
tion.  Special  purpose,  “little*  languages  are  a  nice  Idea, 
but  unless  they  are  economical  to  develop  and  apply, 
they  most  probitoly  will  not  be  adopted.  At  Unisys,  a  tool 
exists  that  not  only  supports  language  definition  but  the 
tool  is  written  in  Ada  and  generates  Ada  code  to  accom¬ 
plish  specification  translations.  SSAGS  [Payt82]  (Syntax 
and  Semantics  Analysis  and  Generation  System)  has 
been  in  use  since  198?  (fully  operational  in  an  almost 
total  Ada  configuration  since  1986)  and  has  been  applied 


in  the  development  of  a  number  of  special  purpose  Ian- 
guagestPeasT]] 

Using  SSAGS,  we  developed  syntax  for  both  forms  of 
knowledge  representation  required  for  the  RLF  and  cor¬ 
responding  semantics  for  expressions  written  In  these 
languages.  SNDL  and  RBDL  are  different  because  they 
support  different  sorts  of  information.  However  the  trans¬ 
lation  principles  that  lead  to  the  generation  of  Ada  code 
from  these  languages  are  the  same  for  both  languages. 
From  a  SNDL/RBDL  “spec',  the  SNDL/RBDL  translator 
generates  Ada  code  to  Initialize  the  persistent  (currently 
Ada  file  based)  forms  of  the  data  contained  in  the  specifi¬ 
cations  themselves.  To  actually  initialize  the  machine 
readable  data  structures,  the  generated  programs  need 
merely  be  compiled  and  run. 

AdaKNET  and  AdaTAU  themselves  contain  reverse 
translators  that  enable  the  current  state  of  individual  or 
hybrid  knowledge  bases  to  be  saved  as  ASCII  text  files  of 
SNDL  and  RBDL  specifications.  Thus,  if  any  changes  to 
knowledge  bases  are  made  interactively,  a  snapshot  of 
these  knowledge  bases  can  be  taken.  SNDL  and  RBDL 
specifications  are  themselves  highly  portable  and  are  our 
preferred  means  of  porting  knowledge  bases  to  new 
computing  environments. 

Future  Extensions 

There  are  many  possible  extensions  to  make  to 
AdaKNET.  One  feature  of  KNET,  the  Prolog  progenitor 
of  AdaKNET,  that  is  currently  not  provided  in  AdaKNET  is 
the  notion  of  constraints  whereby  attributes  of  a  subcate¬ 
gory  can  be  automatically  delimited  when  subcategories, 
or  individuals  of  the  subcategory,  are  created.  Without 
some  automatic  way  of  performing  such  limitations  (or 
constraining  actions)  the  AdaKNET  user  is  forced  to  do 
them  by  hand.  More  generally,  experimentation  with  pro¬ 
viding  interlaces  to  AdaKNET  that  support  the  integration 
of  AdaKNET  with  other  knowledge  representation  sys¬ 
tems  would  be  desirable. 

AdaTAU  is  particularly  well-suited  to  providing  “expert* 
navigational  guidance  through  a  complex  domain  model 
such  as  those  definable  with  AdaKNET.  Because  the 
rule  abstractions  are  simple  (and  AdaTAU  rule  bases  are 
implemented  via  Ada  generics),  modifications  to  AdaTAU 
to  support  new  kinds  of  rules  or  Inference  strategies  are 
relatively  easy  to  accomplish.  We  have  already  experi¬ 
mented  with  different  sorts  of  partitioning  and  focusing 
schemes  In  building  Gadfly  and  librarian  applications. 
Other  possible  extensions  to  AdaTAU  include  supporting 
non-monotonic  reasoning  where  rules  can  identify  facts 
to  be  removed  from  the  fact  base  as  well  as  added  to  the 
fact  base.  Careful  truth  maintenance  must  be  provided 
so  that  fact  bases  remain  consistent,  and  rules  can  be 
“unfired*  due  to  the  removal  of  antecedent  facts.  As  is 
the  case  for  AdaKNET,  it  is  possible  to  experiment  with 
different  kinds  of  application  interfaces  to  AdaTAU 
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whereby  application-specific  actions  can  bo  invoked 
under  the  control  of  AdaTAU.  The  results  returned  from 
these  actions  can  then  bo  fed  into  tho  general  inferenco 
process. 

We  plan  to  continue  with  our  hybridization  experiments. 
To  support  this  research,  an  integrated  Knowlodge-Baso 
Description  Language  (KBDL)  is  planned  which  will  sup¬ 
port  proven  hybridization  schemes  as  they  are  devel¬ 
oped.  We  also  intend  to  continue  our  development  of 
Gadfly,  both  in  support  of  librarian  applications  os  well  as 
a  separate  application.  Our  primary  methodology  will  be 
to  concentrate  on  knowledge  engineering  extensions. 
Planned  knowledge  base  enhancements  include  support 
for  additional  Ada  units  such  as  packages  as  well  as 
other  Ada  data  types.  Improvod  and  enlarged  RBDL 
specifications  to  support  more  sophisticated  testing  meth¬ 
odologies  and  parameter  relationships  (such  as  aliasing) 
are  also  under  consideration. 

4.  Librarian  Applications 

The  Reusability  Library  Framework  project  Is  focused  on 
producing  a  whole  family  of  librarian  applications  culmi¬ 
nating  in  a  qualifier  librarian  that  includes  Gadfly  as  a 
testing  agent/quality  assurance  module,  and  which  sup¬ 
ports  full  repository  management  services  over  a  soft¬ 
ware  library  focused  on  a  particular  application  domain. 
There  Is  nothing  Inherent  in  the  approach  taken  In  con¬ 
structing  the  RLF  that  precludes  it  from  being  applied 
over  a  larger,  less  focused  collection  of  software  compo¬ 
nents.  Although  a  general  purpose  reuse  library  could  be 
built  based  on  the  RLF  components  with  very  good  re¬ 
sults.  we  believe  that  the  benefits  realized  from  the  reuse 
of  software  components  will  be  greatest  In  the  near  term, 
where  software  repositories  are  organized  around  narrow 
domains. 

Not  only  will  an  RLF-based  repository  store  Individual 
modules  and  contain  knowledge  about  their  construction 
and  quality,  it  will  also  possess  knowledge  concerning 
how  components  from  the  library  have  been  successfully 
combined  Into  subsystems  that  sotve  particular  problems 
within  the  application  domain.  Knowledge  about  failures 
of  components  when  used  in  Inappropriate  contexts  can 
also  be  maintained.  In  short,  a  domain-focused  library 
should  contain  all  necessary  Information  so  that  new  per¬ 
sonnel  coming  to  work  In  the  application  domain  have  ac¬ 
cess  to  the  collective  wisdom  o  past  system  designers 
and  Implementors. 

New  system  construction  within  such  a  library-based  en¬ 
vironment  can  be  focused  on  the  use  of  components 
found  within  the  repository,  with  new  module  design  and 
construction  being  pursued  only  as  a  last  resort.  When 
new  parts  are  constructed,  they  should  be  designed  with 
a  clear  understanding  of  their  storage  and  reuse  in  a  re¬ 
pository  setting.  Relationships  to  currently  installed  mod¬ 
ules  must  be  established  when  the  new  part  is  checked 
into  the  system.  In  addition,  a  quality  analysis  session 


should  be  required  whero  the  olferor  of  a  now  component 
Is  queried  regarding  explicit  and  implicit  assumptions 
about  the  design,  testing  and  intended  usage  of  the  com¬ 
ponent.  Such  a  dialogue  session  will  ensure  that  a  pro¬ 
spective  user  of  the  component  has  sufficient  information 
to  chooso  among  several  candidate  components  for  a 
particular  application. 

Browsing  Librarian 

Our  first  sample  librarian  application  Is  simply  called 
Ubraty_Browser.  Its  design  was  adapted  from  the  de¬ 
sign  ol  an  early  browser-editor  application  which  was 
used  to  test  the  functioning  of  AdaKNET. 
Library_Browser  reties  on  a  user-guided  approach  to 
navigating  within  the  library  (SNDL-providod)  knowledge 
base.  This  method  of  user-controlled  navigation  might  be 
the  preferred  method  In  a  small  library  or  for  a  user  who 
has  consulted  the  library  frequently  (or  a  domain  expert 
who  participated  In  its  construction). 

From  a  particular  library  category,  tho  user  can  navigate 
to  any  other  category  or  subcategory  by  typing  its  name. 
The  attributes  of  a  particular  category  can  be  examined 
as  a  group  or  Individually.  A  history  list  of  all  recently  ex¬ 
amined  categories  is  provided  so  that  the  user  has  a 
sense  of  where  he  or  she  has  boon  browsing  in  the  li¬ 
brary.  It  is  possible  to  generate  a  list  of  all  subcategories 
of  a  given  category  so  that  a  sonse  of  the  depth  and 
breadth  of  the  classification  scheme  can  be  obtained. 

Once  the  user  has  navigated  to  a  location  where  particu¬ 
lar  components  have  been  identified,  the  file  system  loca¬ 
tion  of  these  software  components  can  be  obtained  along 
with  particular  values  of  attributes  that  the  software  com¬ 
ponent  must  have  based  on  its  membership  within  a  par¬ 
ticular  component  category.  In  early  librarian  versions, 
the  actual  location  of  the  component  is  provided,  rather 
than  the  component  Itself.  The  component  can  then  be 
Inspected  with  a  system  editor. 

This  first  version  also  provides  for  Insertion  and  deletion 
of  both  knowledge  and  software  components  by  the  ex¬ 
pert  user.  Such  privileges  were  naturally  present  In  the 
AdaKNET  browser-editor  where  all  aspects  of  managing 
the  semantic  network  were  under  scrutiny.  In  a  produc¬ 
tion-quality  librarian,  such  modification  privileges  might 
well  be  restricted  to  a  single  user  (a  library  administrator) 
or  at  least  a  small  group  of  users  (a  library  review  board). 

The  sophistication  of  this  drivt  your-own  librarian  Is  limit¬ 
ed  by  the  extent  of  the  knowledge  engineering  that  has 
been  done  for  the  domain  and  the  Individual  components 
housed  within  the  library.  Search  and  retrieval  perfor¬ 
mance  is  based  on  the  navigational  savvy  of  the  library 
user  as  well  as  the  general  browsing  capabilities  over  the 
domain  model  that  are  provided  by  the  AdaKNET 
Browser_Editor.  This  method  of  Interface  is  more  appro¬ 
priate  to  particular  situations  and  is  not  intended  for  gen¬ 
eral  use. 
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Class!  tit  r  Librarian 

The  ctassifior  librarian  utilizos  the  Knowledge  baso  struc- 
lure  ilsolf  to  load  the  user  through  a  dlaloguo  aimed  at  io- 
eating  soltwaro  components  that  might  bo  ol  Interest. 
When  locatod  ai  a  particular  category,  thoro  aro  two 
sources  ol  additional  information  that  can  automatically 
be  Inspected  —  tho  subcatogorios  which  exist  at  the  cur¬ 
rent  category,  and  the  attributes  that  distinguish  one  sub¬ 
category  from  the  next. 

After  the  user  has  brewsod  to  a  point  in  tho  knowledge 
base  and  Is  unablo  to  dotormine  whore  to  go  next,  or  por- 
haps  storting  at  the  vory  highest  level  of  tho  knowledge 
base,  choices  are  offered  to  the  user  based  on  the  avail¬ 
able  branch  points  that  oxist  from  tho  current  node.  II  tho 
user  Is  able  to  mako  a  choice  based  on  a  name  In  tho  list 
of  possible  subcatogorios,  the  user  chooses  one  and 
then  the  classifier  librarian  orao  again  prosonts  a  list  of 
possible  subcatogorios  representing  where  to  go  next. 
This  process  continues  until  tho  user  is  led  to  the  bottom 
level  ol  the  domain  network  at  which  point  no  possible 
subcatogorios  exist,  or  otso  the  usor  can  opt  out  of  tho 
automatic  descent  at  which  point  the  browsing  modo  de¬ 
scribed  previously  is  automatically  re-enabled. 

One  reason  to  ond  this  simple  modo  of  descent  is  that 
the  names  of  the  possible  subcategories  do  not  them¬ 
selves  present  sulficiont  information  to  make  a  choice.  In 
this  case,  the  user  can  elect  to  have  the  systom  display 
the  differences  botwoon  any  two  categories  that  woro 
enumerated  In  a  previous  list  of  choices.  The  user,  hav¬ 
ing  examined  the  differences,  can  go  directly  to  a  catego¬ 
ry,  or  else  the  guided  modo  can  be  resumed  so  that  a  fur¬ 
ther  descent  Is  conducted  in  a  controlled  manner. 

Another  reason  to  abort  the  guided  search  would  be  if  the 
list  of  subcategories  to  consider  did  not  include  any  that 
were  likely  to  contain  a  software  component  with  tho  right 
properties.  In  this  case  tho  usor  can  oloct  to  go  to  anoth¬ 
er  category  to  conduct  tho  search  from  there,  or  perhaps 
return  several  levels  back  the  descent  path  so  that  an  al¬ 
ternate  choice  can  be  made  and  a  new  descent  path  fol¬ 
lowed. 

Finally,  the  user  may  locate  the  proper  subcategory  be¬ 
fore  the  end  of  the  descent  path  is  reached.  This  would 
occur  if  the  user  actually  found  a  category  that  was  ex¬ 
pected  to  contain  software  components  with  the  desired 
characteristics.  Such  a  category  may  indeed  have  sub¬ 
categories  with  special  properties  but  these  specializa¬ 
tions  may  not  be  desired.  Or,  the  user  may  actually  in¬ 
tend  to  create  a  new  subcategory  which  is  to  contain 
some  some  new  software  components.  Once  again,  do¬ 
main  model  modifications  (caused  by  changes  lo  subcat¬ 
egories  and  their  attributes)  or  even  simple  software 
component  additions  or  deletions  may  be  strictly  con¬ 
trolled  by  access  privileges  so  that  library  integrity  can  be 
assured. 


Advisor  Librarians 

The  success  ol  a  structure-guided  tour  of  tho  domain 
knowledge  base  depends  on  tho  richness  of  tho  compo¬ 
nent  taxonomy  as  well  as  on  the  fact  that  a  direct  path 
exists  from  a  given  point  to  an  eventual  stopping  point. 
In  a  largo,  comptox  knowledge  base  such  a  path-based 
search  approach  is  likely  to  be  weak  and  unwieldy. 
Additionally,  only  one  segmont  ol  the  usor  community  Is 
Hkoly  to  bo  wotl-sorvod  by  a  particular  taxonomical  orga¬ 
nization  (at  best  perhaps  the  ‘average*  user).  Different 
usor  ciassos  will  come  to  tho  repository  with  varying 
amounts  of  domain  knowledge  and  navigational  skills. 
For  the  repositoiy  to  be  useful  to  a  largo  community  of 
usors,  it's  management  must  support  tho  needs  of  differ¬ 
ent  sogments  of  the  community. 

While  (hero  can  bo  only  one  taxonomy  In  offoct  at  any 
one  time,  dilferont  levels  of  support  can  be  provided 
based  upon  the  class  and  skill  level  of  the  usor.  Explicit 
domain  ‘oxports*  fill  the  needs  of  those  dissimilar  usor 
profiles.  Domain  expertise,  in  the  form  of  navigational 
support  and  guidance,  can  be  supplied  through  various 
advising  rule  basos  implemented  with  AdaTAU.  Like 
Gadfly,  these  rule  bases  are  distributed  throughout  the 
static  domain  modol  represented  through  AdaKNET.  But 
unlike  Gadfly,  the  services  of  distributed  AdaTAU  provide 
the  capability  of  making  long  distance  jumps  within  the 
domain  taxonomy. 

Advising  functionality  can  play  a  number  of  different  roles 
In  the  effective  use  of  a  domain  specific  repository. 
Primarily,  advising  rule  bases  provide  navigational  guid¬ 
ance  over  a  complex  network  and  oncode  heuristics  re¬ 
garding  effective  retrieval  and  composition  of  compo¬ 
nents  In  the  library.  Rule  bases  can  support  different 
project  (development,  management,  QA, ...)  as  well  as 
domain  knowledge  (novice  through  expert).  Such  di¬ 
verse  classes  of  users  clearly  have  different  alms  and 
needs  in  using  the  library,  and  usage  advice  should  be 
given  accordingly. 

Another  role  is  to  connect  software  components  to  one 
another  that  are  not  directly  connected  (or  are  only  Indi¬ 
rectly  connected  through  several  levels  within  the  taxono¬ 
my).  In  the  benchmark  domain,  for  example,  benchmark 
programs  are  useful  only  when  compiled  with  related 
timer  routines.  Taxonomically,  these  timer  components 
might  be  quite  unrelated  to  the  benchmark  programs 
which  are  categorized  by  the  feature  they  test,  or  the 
benchmark  suite  they  are  located  In.  Of  course,  one  of 
the  attributes  of  a  subcategory  ought  to  be  the  category 
which  contains  such  related  pieces  of  software.  But 
using  such  conceptual  information  might  be  diificult  for 
the  novice  or  casual  library  user.  In  such  cases,  rules 
can  advise  the  user  of  the  required  relations,  and  even 
provide  the  navigational  mechanism  from  one  category 
(or  component  in  a  category)  to  another. 
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Advising  can  also  ho!p  with  the  task  o(  system  configura¬ 
tion  from  components  installed  In  tho  copository. 
Successful  subsystems  that  have  been  built  out  of  Cbraty 
components  can  be  represented  by  special  purpose  rules 
that  connect  together  thoso  components  and  provide  a 
navigational  path  tliat  can  bo  used  to  rccreato  tho  con¬ 
struction  of  tho  subsystem.  Othor  systom  configuration 
data  can  be  included  In  the  knowledge  base  to  provide 
factual  design  and  usago  information  and  to  point  out  po¬ 
tential  trouble  spots. 

An  important  class  of  rules  can  bo  established  for  trou¬ 
ble-free  management  of  tho  repository.  Library  manage¬ 
ment  can  be  a  troublesome  task  especially  for  a  largo 
and  dynamic  application  domain.  Rules  can  provide 
guidance  for  safe  Insertions  of  new  components  into  tho 
repository,  as  wolf  as  coverage  analysis  so  that  when 
parts  are  offered  for  Installation,  tho  library  is  first  exam¬ 
ined  for  related  parts  and  for  necossary  relationships. 
Using  the  benchmark  domain  as  an  example,  a  now  fea¬ 
ture  benchmark  should  not  be  installed  without  an  associ¬ 
ated  timer  routine.  By  allowing  library  management  only 
under  rule-basod  guidance,  tho  library  administrator 
could  in  (act  be  less  than  a  domain  oxpen. 

Qualifier  Librarian 

The  quatity  of  parts  placed  in  a  library  is  critical  to  tho 
success  of  part  reuso.  A  library  framowork  must  provide 
quality  assurance  for  the  parts  currently  within  the  library, 
as  well  as  for  parts  offered  for  Inclusion  within  the  library. 
Quality  assurance  encompasses  more  than  enforcing  a 
testing  methodology.  Nonetheless,  a  good  place  to  begin 
to  provide  quality  measures  Is  to  assure  a  prospective 
borrower  that  the  part  meets  some  minimal  standards 
and  that  certain  kinds  of  tests  have  been  conducted  on 
the  part. 

Gadfly  Is  a  knowledge-based  testing  assistant,  built  on 
AdaKNET  and  AdaTAU,  and  so  an  obvious  first  step  is  to 
Incorporate  Gadfly  Into  the  RLF  framework.  Gadfly's 
knowledge  bases  wore  Initially  prepared  to  support  sim¬ 
ple  black  box  Ada  unit  testing  concentrating  on  the  pa¬ 
rameter  profiles  of  a  unit  under  tost.  For  an  application- 
specific  domain  library,  knowledge  about  the  domain  it¬ 
self  needs  to  be  added  so  that  such  knowledge  guides 
the  test  analysis  and  generation  process.  Gaddy's  em¬ 
phasis  on  module  parameter  profiles  must  also  be  modi¬ 
fied  to  accomodate  its  use  with  general  software  compo¬ 
nents  which  may  not  have  any  parameters  within  their 
visible  external  Interfaces. 

In  a  library  setting,  Gaddy  can  be  applied  for  two  different 
purposes.  When  a  part  is  offered  to  the  library,  Gaddy  is 
invoked  to  establish  the  degree  and  types  of  testing  that 
need  to  be  done  in  order  that  the  part  be  approved  for  in¬ 
clusion  In  the  library.  In  a  production-quality  version  of 
the  qualifying  librarian,  a  part  should  be  officially  validat¬ 
ed  according  to  the  test  plan  generated  by  Gaddy  before 
it  is  officially  installed  in  the  library. 


Gaddy  can  also  be  an  option  to  be  invoked  by  a  borrower 
of  a  component  from  the  library.  In  this  form,  Gaddy 
seeks  to  probe  the  borrower  tor  assumptions  regarding 
the  Intondod  performance  and  orror  handling  characteris¬ 
tics  of  the  modulo  being  sought.  If  tho  borrower's  expec¬ 
tations  don't  match  the  module  undor  consideration,  an 
alternate  module  can  bo  suggested.  At  tho  very  least, 
the  desired  characteristics  ol  the  pan  are  compared 
against  tho  characteristics  established  during  the  Gaddy 
session  conducted  when  tho  part  was  installed  Into  the  li¬ 
brary.  The  user  is  not  loft  In  tho  dark  about  tho  suitability 
of  tho  part  If  this  Information  is  captured  In  tho  knowledge 
base  itself. 

Gaddy  just  scratches  tho  surface  of  tho  probtom  ol  quality 
assurance  for  sottwaro  libraries.  Just  as  domain  knowl¬ 
edge  can  be  capturod  to  support  effective  cataloging  and 
retrieval  ol  software  components,  domain  knowledge  is 
the  key  to  providing  effective  quatity  assurance  for  library 
patrons,  as  wed  as  for  software  component  authors. 

Future  Directions 

There  are  many  opportunities  for  growth  of  the  RLF 
project,  and  tho  library  framowork  in  particular.  Our  near 
term  plan  focuses  on  exploring  several  other  application 
domains  and  strengthening  tho  Gaddy/Quafity  Assurance 
capabilities  of  the  prototype.  Wo  can  best  critique  our 
knowledge  collection  and  representational  abilities  by  try¬ 
ing  to  buitd  relatively  large  modols  over  sevoral  different 
application  areas  with  different  characteristics.  Some  ex¬ 
amples  of  such  applications  areas  are  real-time,  embed¬ 
ded  systems  (such  as  missilo  guidance  software),  data 
management  systems  (such  as  those  required  to  support 
military  logistics  planning  and  control),  and  user-interface 
models  such  as  the  X  Window  Systom. 

Our  foremost  longor-term  desire  is  to  replace  the  underly¬ 
ing  primitive  uso  of  the  Ada  file  I/O  sorvices  with  an  effi¬ 
cient  and  powerful  data  base  management  system. 
There  is  simply  too  much,  and  too  wide  a  variety  of,  data 
to  be  processed  effectively  with  raw  I/O  operations  on 
large  numbers  of  Ada  files.  Using  a  DBMS  (or  preferably 
an  Object  Management  System  (OMS)),  we  can  Install 
both  the  knowledge  base  constituents  (nodes  and  at¬ 
tributes  In  a  semantic  network,  and  facts  and  rales  from 
rale  bases)  and  tho  software  components  themselvos  in 
a  unified  database  system.  Distributed  systems  are  cer¬ 
tain  to  rise  in  usago  and  popularity,  and  by  incorporating 
a  distributed  DBMS  (OMS),  we  can  migrate  the  RLF  nat¬ 
urally  to  such  systems.  A  system  that  provides  access  to 
a  heterogeneous  system  would  be  ideal  in  that  knowl¬ 
edge  base  components  coutd  be  located  on  a  fast  local 
server,  while  the  components  themselvos  could  be  stored 
at  various  distributed  sites  served  by  slower  speed  serv¬ 
ers.  A  DBMS/OMS  would  also  facilitate  the  handling  of 
more  diverse  software  artifacts  such  as  requirements,  de¬ 
sign  specs,  test  cases  and  reports,  etc. 
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W#  would  like  to  expand  our  repository  management  ca¬ 
pabilities.  Possibilities  include  maintaining  and  reporting 
usage  statistics  about  component  withdrawals,  maintain¬ 
ing  and  reporting  reliability  measures  based  on  borrowor 
reports  about  using  withdrawn  parts  in  applications,  and 
audit  trails  that  provide  library  usago  information  and  per¬ 
haps  lead  to  the  creation  of  Individual  usor  profiles.  Such 
profiles  could  support  individualized  start  up  settings  for 
preferred  mode  of  interaction  (browsor,  classifier,  advi¬ 
sor)  and  could  automatically  chango  usago  modes  as 
user  experience  increases. 

Finally  we  would  like  to  expand  the  native  intelligence  of 
the  librarian  itself.  Wo  envision  a  pro-activo  librarian  that 
could  automatically  manage  the  repository  and  underly¬ 
ing  knowledge  bases.  Expanded  roles  and  functionality 
for  such  a  librarian  includo  the  rearrangement  of  compo¬ 
nents  and  categories  based  on  usage  frequencies  and 
the  installation  of  new  components,  identification  of  miss¬ 
ing  components  or  library  categories  which  aro  lacking  in 
quality  or  numbers  of  components,  and  even  the  actual 
solicitation  of  new  components  based  on  unsuccessful 
withdrawal  attempts.  A  related  long-torm  goal  Is  to  incor¬ 
porate  the  use  of  generation  techniques  so  that  a  tightly 
coupled  collection  of  software  components  could  them- 
sehms  bo  replaced  by  a  generator  and  a  much  smaller 
collection  of  specifications.  Each  component  in  the  fami¬ 
ly  could  be  produced  by  tho  generator  from  the  proper 


5.  Experiences  With  Ada 

Various  Ada  features  have  been  positive  factors  in  the 
design,  coding,  Implementation,  and  Integration  of  tho 
knowledge  representation  systems  and  applications  de¬ 
veloped  during  the  RLF  project.  Certain  aspects  of  the 
current  generation  of  compilers  and  run-time  systems 
posed  obstacles  that  needed  to  be  overcome.  This  sec¬ 
tion  presents  some  of  our  basic  ‘lessons-learned’. 

Our  approach  to  the  construction  of  AdaKNET  and 
AdaTAU  emphasized  the  basic  design  principle  of  data 
abstraction  and  depended  heavily  on  the  use  of  Ada  ge¬ 
nerics  and  exception  handling.  By  concentrallng  on  a 
careful  and  reasoned  use  of  Ada  capabilities,  we  were 
able  to  develop  systems  with  traditional  Al  functionality 
that  also  promote  system  maintainability  and  evolvability. 
Our  plan  for  growth  and  evolution  of  our  systems  in¬ 
cludes  analysis  of  various  feature  sets  that  are  deemed 
useful  within  possible  configurations  of  deployed  sys¬ 
tems.  This  domain-analysis  sets  the  stage  for  early  sys¬ 
tem  versions  that,  while  not  fully  equipped,  are  potentially 
useful  in  applications  that  do  not  require  the  entire  com¬ 
plement  of  features.  Thus  prior  domain  analysis  leads  to 
an  orderly  evolution  from  limited  prototypes  to  a  final 
product.  In  fact,  such  early  systems  are  also  more  com¬ 
pact  and  more  efficient  than  their  full-featured  counter¬ 
parts  and  so  may  be  appropriate  where  there  are  re¬ 
source  constraints  of  one  type  or  another. 


Careful  design  also  affords  significant  opportunities  for 
reuse  at  the  module/package  level  as  welt  as  the  sub¬ 
system  level.  For  example,  during  the  design  of 
AdaKNET,  we  identified  the  nood  for  a  tables  abstraction 
that  simultaneously  provided  persistence  for  the  objects 
and  relationships  being  managed  by  AdaKNET  os  well  as 
for  efficient  access  to  stored  data.  Later,  when  tho  im¬ 
plementation  of  AdaTAU  required  a  means  for  AdaTAU 
structures  to  be  made  persistent,  the  tobies  genoric  pro¬ 
vided  the  nocosssary  functionality.  Our  experiences  with 
Gadfly  and  tho  various  librarian  applications  ore  ample 
proof  of  tho  reusability  of  tho  AdaKNET  and  AdaTAU 
subsystems  themselves. 

Reuse  of  another,  perhaps  more  powerful  sort,  Is  provid¬ 
ed  by  the  use  of  generation  techniques.  From  our  high- 
level  knowledge  base  specifications,  we  automatically 
generate  Ada  code  to  initialize  machlne-processablo 
knowledge  bases.  Because  the  specification  language 
processors  are  themsolves  generated  from  their  own 
high-level  specifications,  we  need  not  hand-write  code  to 
create  parsers  and  lexical  analyzers  for  these  languages. 
The  small  amount  of  handwritten  code  that  is  needed  to 
support  the  semantic  processing  provided  in  the  lan¬ 
guage  is  often  an  easy  adaptation  of  code  provided  for 
other  languages  that  were  developed  using  the  Ada- 
based  compllor-compiter  technology  developed  here  at 
the  Paoti  Research  Center. 

The  adaptation  of  the  RLF  knowledge  base  components 
to  new  application  domains  is  achieved  in  part  by  writing 
high-level  specifications  of  the  knowledge  that  captures 
the  new  domain  and  then  automatically  generating  the 
Initialization  code.  Only  a  relatively  small  amount  of  ap¬ 
plication-specific  code  needs  to  be  handwritten.  Another 
advantage  of  the  use  of  specification  languages  is  that 
knowledge  descriptions  can  be  written  by  domain  experts 
who  are  not  necessarily  Ada  experts. 

Our  collective  project  experiences  were  not  totaily  posi¬ 
tive,  however.  Many  of  our  difficulties  can  be  traced  to 
problems  with  the  Ada  compiler  and  run-time  systems 
that  we  employed  during  the  project.  We  faced  problems 
with  reuse  of  outside  software  components,  execution 
performance  of  our  own  code,  and  a  less-than  trouble- 
free  port  from  a  workstation  platform  to  a  PC  platform. 
For  the  most  part,  the  blame  for  these  problems  cannot 
be  attached  to  Ada,  but  rather  to  our  own  inexperience 
and  to  the  limitations  present  In  today’s  Ada  language 
systems. 

Our  foremost  problem  was  a  proiound  lack  of  control 
from  within  our  system  of  dynamic  memory  -  memory 
that  is  allocated  through  the  use  of  the  Ada  new  com¬ 
mand.  Although  we  attempted  to  be  as  careful  as  we 
could  possibly  be  regarding  memory  management,  re¬ 
turning  memory  back  to  the  memory  pool  (heap)  when  no 
longer  needed,  we  could  not  control  process  memory 
growth  using  completely  portable  Ada  code.  A  large  part 
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of  the  problem  turned  out  to  bo  tho  Ada  run-timo’s  own 
use  of  the  heap  for  I/O  buffers  among  othor  things. 
Because  tho  application’s  use  of  tho  hoap  was  conflicting 
with  the  system’s  own  use,  our  applications  Invariably 
experience  large-scale  heap  fragmontation  and  subse¬ 
quent  performance  degradation.  After  talking  to  several 
Ada  vendors,  it  became  cloar  that  the  only  way  to  com¬ 
pletely  control  heap  momory  was  to  take  matters  Into  our 
own  hands  and  write  code  specific  to  tho  compilation  sys¬ 
tem  In  uso,  thereby  dpriori  sacrificing  portability. 

An  Interim  solution  turned  out  to  bo  os  simple  as  provid¬ 
ing  a  limited  amount  of  momory  management  from  within 
each  basic  abstraction.  For  oxample,  object  tree  lists  aro 
managed  from  within  oach  of  tho  basic  abstractions  such 
as  lists,  sets  and  tables.  Whonovor  such  objects  are  allo¬ 
cated  (using  new),  they  aro  never  rcloascd  using  un¬ 
checked  deallocation,  but  rather  are  attached  to  the  free 
list  when  the  object  is  logically  no  longor  needed.  Our 
experience  to  date  Is  that  though  process  momory  does 
creep  upwards  as  execution  continues,  this  growth  Is  tol¬ 
erable,  and  pedormanco  is  not  severely  affected.  Ono 
very  Important  lesson-learned  Is  that  for  applications  re¬ 
quiring  extensive  uso  of  dynamic  memory,  heap  manage¬ 
ment  Is  not  a  luxury,  ora  performance  rolated  fine-tuning, 
but  rather  a  necessity. 

In  addition  to  less-than-podect  memory  managemant  (e. 
g.  file  buffers  are  allocated  on  the  heap,  but  are  never 
deallocated  alter  the  file  is  closed),  we  also  experienced 
a  number  of  other  compiler  system  problems.  Both  com¬ 
piler  systems  we  used  exhibited  Ada  library  management 
and  pedormance  problems  as  well.  We  had  problems  in¬ 
volving  the  use  of  generics  (genen'c  instantiation  glitches 
and  compile-time  pedormance  problems  with  nested  ge¬ 
netics),  exceptions  (poor  propagation  pedormance),  and 
the  use  of  Ada-Make  facilities  which  are  supposed  to  au¬ 
tomate  the  process  of  generating  executables  after 
changes  to  various  source  files.  Today’s  generation  of 
Ada  compilers  require  large  amounts  of  disk  space  to 
suppod  their  custom  forms  of  library  management. 
Executable  object  files  also  tend  to  be  very  large  (certain- 
ly  compared  to  other  less  powedul  languages).  We  ex¬ 
pect  many  of  these  problems  to  disappear  as  compiler 
vendors  Improve  their  products. 

Finally,  although  portability  is  aided  by  Ada,  It  is  not  as¬ 
sured,  nor  Is  the  process  made  trivial.  When  porting  our 
system  from  one  compiler  to  another  on  the  same  hard¬ 
ware,  we  experienced  difficulties  due  to  library  manage¬ 
ment  differences  as  well  as  compiler  limitations.  When 
porting  from  one  machine  to  another,  using  the  same 
compiler  we  once  again  ran  into  compiler  limitations,  as 
well  as  resource  limitations  (in  a  PC  environment).  We 
also  experienced  minor,  but  tedious,  operating  system 
consequences.  For  example,  due  to  our  use  of  text  files 
to  store  knowledge  bases,  the  pod  to  an  environment 
with  very  strict  file  naming  conventions  was  not  as  easy 
as  expected. 


6.  Summary 

Somo  idea  ol  the  scope  and  size  of  the  projoct  is  ob¬ 
tained  by  examining  tho  dovolopmont  platforms  that  were 
used  in  working  on  the  projoct  and  some  statistics  that 
summarize  the  largo  amount  ol  code  and  documentation 
that  have  boon  produced.  Our  primary  dovolopmont  en¬ 
vironment  consisted  of  Sun  Microsystems  workstations 
(3/50,  3/60  and  3/75‘s)  oach  ol  which  contained  a  mini¬ 
mum  of  4  mogabytos  of  momo.y  and  was  operated  under 
Sun  operating  system  3.4.  Available  Ada  compilation 
systems  included  Verdix  Ada  Dovolopmont  Systems 
(VADS)  5.5  and  Atsys  3.2.  Our  initial  development  took 
place  using  VADS  mainly  becauso  ol  our  Initial  familiarity 
with  this  systom.  As  work  proceeded,  wo  endeavored  to 
use  the  AEsys  compiler  to  remove  any  system  specific  de¬ 
pendencies.  To  demonstrate  machine  portability,  as  RLF 
components  were  completed  and  refined,  the  source 
code  was  transferred  to  a  Unisys  PW/V500  computer 
(IBM  compatible,  using  MS-DOS  3.3)  and  compiled 
under  the  Atsys  compilation  systGm  which  includes  an 
extended  memory  board. 

The  system,  at  the  time  this  paper  is  being  written,  is 
comprised  of  70  handwritten  Ada  packages  (23,000  Ada 
statements,  60,000  lines  including  comments)  and  84 
generated  packages  (for  the  language  translators)  con¬ 
taining  approximately  13,000  Ada  statements. 
Knowledge  base  descriptions  (RBDL  and  SNDl  specifi¬ 
cation  files)  contain  over  6,000  clauses  (each  clause 
roughly  equivalent  to  an  Ada  statement).  Over  5C0 
pages  of  documentation  have  been  produced  during  this 
project.  This  documentation  Includes  design  reports, 
user  manuals  (both  as  on-line  ASCII  text,  and  formatted 
printed  copies)  and  presentation  materials  from  several 
conferences  Including  TRI-Ada  '88  and  AIDA  -88. 

The  basic  achievement  of  the  RLF  projoct  is  the  provi¬ 
sion,  in  a  demonstrable  prototype,  ol  a  general  frame¬ 
work  for  the  construction  of  domain-specific  libraries  of 
Ada  software  components.  The  domain-models  express¬ 
ible  using  the  RLF  components  support  the  statement 
and  evolution  of  detailed  taxonomic  descriptions  and  sup¬ 
portive  search  capabilities  that  enable  hlgh-impact  reuse. 
In  addition,  we  provide  automated  support  for  users  of 
reuse  libraries  Including  component  selection,  insertion 
and  qualification. 

An  Important  incremental  achievement  was  the  success¬ 
ful  application  of  knowledge-based  technology  to  the 
area  of  Ada  component  testing  (Gadfly).  Both  of  these 
achievements  were  accomplished  based  on  the  produc¬ 
tion  of  general-purpose  knowledge-based  components  in 
Ada.  These  tools  themselves  support  the  Incremental 
addition  of  knowledge-based  processing  to  other  Ada 
products  and  systems.  The  project  also  represents  a 
successful  experiment  in  the  hybridization  of  dual  knowl¬ 
edge-representation  systems  that  together  insure  robust 
coverage  of  procedural  and  declarative  forms  of  informa¬ 
tion. 
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Finally,  wo  wore  ablo  to  oxporfmont  with  innovative  uses 
ol  Ada  for  the  implementation  of  knowledge-based  tools. 
Wo  have  foamed  a  groat  deal  about  the  techniques  and 
approaches  that  support  tho  design  of  reusable  softwaro 
components  and  beHovo  that  this  knowledge  can  drivo 
further  work  on  tho  RIF  project  as  well  os  guido  us  as  wo 
cevolop  our  own  component  reuso  Ibranes. 
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Abstract 

In  this  paper  we  discuss  hypertext  as 
a  tool  for  describing  taxonomies  of  Ada 
packages  in  order  to  facilitate  their 
reuse.  Our  basic  preaise  is  that  the 
primary  inhibitor  to  the  reuse  of  software 
conponents  is  understanding.  Ve  describe 
a  component  os  on  inforaaclon  "web"  of 
attributes,  containing  specification, 
implementation,  and  usage  inforaaclon. 

The  hypertext  model  is  used  to  describe 
component  information  webs,  alternate 
taxonomic  structures  lending  to  these 
webs,  and  class  Information  webs 
describing  Inforaaclon  coaaon  across 
coaponenc  webs. 


Introduction 

Reusability  is  a  noble  goal  to  shoot 
for  In  a  software  engineering  cnvircnnent. 
Its  advantages  ore  obvious.  Development 
costs  con  be  decreased  by  rousing  code, 
algorithms,  module  specifications, 
subsystem  designs,  etc.  Reliability  can 
also  be  improved  by  reusing  well- 
engineered,  well-documented ,  well-tested 
parts  from  a  parts  library.  In  fact,  it 
has  been  argued  that  the  advantage  of 
increased  reliability  alone  justifies 
reuse,  even  if  development  costs  might  be 
increased. 

Unfortunately  a  number  of  inhibitors 
exist  that  tend  to  negate  the  advantages 
described  above.  The  amount  of  work 
required  to  find  a  pre-wrleten  port 
(whether  in  a  repository  or  book),  to 
decide  whether  or  not  it  is  applicable  to 
the  problem  domain,  and  to  integrate  it 
into  a  system  might  more  than  offset  the 
savings  gained  from  not  having  to  develop 
the  pare.  In  addition,  the  "shoe-horning" 
of  a  pre-written  part  into  a  system  might 
lead  to  reliability  problems  at  the  system 
integration  level. 

A  good  deal  of  work  has  been  done  on 
the  organization  and  retrieval  of  reusable 
software  components  [2],  Unfortunately, 


little  work  has  been  done  on  the 
evaluation  problem,  l.e.,  the 
understanding  problem.  Assuming  that 
components  stored  in  a  library  are  well- 
designed  for  reuse,  and  assuming  also  that 
there  exists  a  way  to  organize  these 
components  for  retrieval,  the  problem 
still  remains  as  to  how  the  components 
will  be  evaluated  once  retrieved.  There 
is  usually  a  wealth  of  knowledge  that  muse 
be  considered  when  performing  such  an 
evaluation,  and  little  consideration  has 
been  given  to  tools  to  aid  in  this 
"understanding"  process.  One  such  class 
of  tools,  based  upon  the  hypertext  model, 
seems  to  be  the  right  approach  to  the 
problem. 

Hypertext  cools  allow  the  user  to 
create  webs  of  annotated  nodes  and  links, 
manipulate  information  (textual, 
graphical,  voice,  etc.)  within  the  nodes 
and  links,  and  navigate  the  webs  by 
various  textuol  and  spatial  commands.  At 
UMalne  wo  have  constructed  the  hypertext- 
like  system  SceCraph  (6],  in  Ada,  on  our 
Vax  workstations,  and  have  also  made  heavy 
use  of  HyperCard  [1],  a  Macintosh  tool 
providing  a  good  deal  of  hypertext 
functionality.  'Jo  have  used  SeeGraph  to 
store  and  retrieve  the  knowledge  web  of 
information  embodying  the  SceCraph  system 
Itself,  and  are  using  HyperCard  to 
construct  the  knowledge  webs  surrounding 
both  the  taxonomies  ond  component  parts  cf 
the  Ada  Gooch  Components  [3]  and 
McDonncll-Douglns  CAMP  parts  [A]. 

Hypertext  is  not  in  itself  a 
solution.  One  must  be  careful,  when 
constructing  hypertext  webs,  that  their 
structure  does  not  get  out  of  hand.  When 
using  ill-defined  hypertext  structures  I 
ob  reminded  of  the  hacker's  game  of 
Adventure.  I  recall  entering  the  room  of 
a  friend's  ten  year  old  son,  being  omozed 
to  sec  the  complete  map  of  the  Adventure 
"world"  attached  to  a  good  portion  of  his 
wall.  Without  such  a  map,  it  is  almost 
impossible  not  to  get  lost  in  this 
"world".  The  sane  thing  tends  to  happen 
in  hypertext. 
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Hypertext  19  to  information 
structuring  as  goto?  are  to  programming. 
Early  writers  el  progress  using  sequence 
and  transfer  of  control  operations  oust 
have  aald,  "What  wonderfully  eeaplex 
systems  we  can  construct  -  systems  to 
control  robots,  guide  aisailes,  balance 
our  checkbook!  ...  Amaslngt".  We  oust 
view  hypertext  In  this  aase  Banner, 

Methods  oust  be  developed  that  parallel 
the  systems  design  notions  of  structured 
progressing,  information  hiding,  and 

abstraction.  This,  to  anyone  forced  to 
build  such  webs,  should  be  obvious. 

We  have  discussed  the  SecCrmph  systea 
in  (7).  In  this  paper  we  concentrate  on 
our  experlsents  in  HyperCard.  We  show  the 
structure  and  content  of  coaponent 
lnforaaeion  webs  as  well  as  the 
flexibility  of  the  hypertext  model  in 
allowing  for  the  construction  of  alternate 
taxonomic  structures  of  components  and 
sharing  of  component  attributes.  We 
finish  by  discussing  the  usefulness  of 
HyperCard  as  an  application  generator,  and 
the  Implications  of  this  for  reuse. 


A  Kate  about  the  Example  Coaponent 
libraries 

In  our  study  we  have  made  use  of  both 
Grady  Hooch's  coaponent  taxonomy  and  the 
McDonncll-Douglaa  CAMP  (Comaon  Ada  Missile 
Packages)  conponents.  Hooch's  coaponent 
collection  includes  approxiaately  500  Ada 
"computer  science  domain"  components, 
Including  a  number  at  variations  of 
stacks,  queues,  graphs,  sorts,  etc.  The 
McDonnell-Pouglas  collection  consists  of 
approximately  200  Ada  components, 
containing  both  computer  science  domain 
packages  similar  to  Hooch's  ns  well  as 
components  particularly  suited  to  missile 
guidance  system  software. 


Components  aa  Information  Webs 

The  problem  with  many  component 
libraries  Is  that  the  code  is  considered 
to  be  Che  component  when  for  purposes  of 
understanding  it  Is  only  one  attribute  of 
the  component.  Generally  there  exists  (or 
should  exist)  a  significant  body  of 
knowledge  about  a  coapononc,  broadly 
divided  into  three  Categories  - 
specification  information.  Implementation 
Information,  and  usage,  or  domain, 
Information.  This  information  exists  as  a 
complex  web  of  faces  about  a  component 
that  must  be  well  understood  In  order  to 
use  It  properly.  In  fact,  it  con  be 
argued  that  this  Information  web  Is  the 
component,  one  smaLl  part  of  which  Is  the 
code.  Furthermore,  to  the  extent  that 
there  is  a  one  to  many  napping  of 


specification  to  implementation,  a 
component  reuld  be  considered  a 
specification  together  with  a  class  of 
implementations,  each  requiring  its  own 
unique  mix  of  resources  (e. senary, 
external  storage,  processor  time,  task 
overhead,  etc.). 

Typically,  component  Information 
takes  the  fora  of  printed  documentation. 
Unfortunately,  printed  media  suffer  from 
the  drawback  of  sequential  organisation. 

A  good  exaaple  of  this  is  the  Ada 
Reference  Manual.  Embedded  within  this 
manual  is  a  web  of  reference  trails  that 
aore  often  than  not  creates  an 
uncomfortable  ante  for  the  Ada  programmer. 
Hypertext  tools  provide  a  much  more 
natural  node  of  access  to  these 
information  webs. 

When  considering  specification, 
iapleaentation,  and  usage  information  more 
closely,  one  quickly  becoaes  aware  of  the 
breadth  of  information  that  can  be 
associated  with  each  nodule.  We  do  so  in 
the  following  sections. 


Specification  lnforaaeion; 

The  specification  is  the  contract 
between  the  user  and  the  Implementator , 
and  as  such  needs  to  bo  as  precise,  yet  as 
simply  stated  as  possible.  This 
Information  night  include  an  Ada  syntactic 
specification,  a  descriptive  and/or 
graphical  presentation  of  the  user's 
mental  model  of  the  specification 
semantics,  formal  semantic  descriptions, 
nnd  syntactic  amt  semantic  justification. 

For  example,  consider  the  web  of 
specification  Information  for  Hooch's 
undirected  unbounded  unmanaged  graph, 
represented  by  the  HyperCard  "card1'  In 
figure  1.  Using  this  web,  the  user  can 
aeeoss  specification  Information  In  a 
variety  of  forms. 

HyperCard  allows  the  user  to  create 
cards  and  place  any  number  of  "buttons"  on 
a  card.  These  buttons  provide  an  area  on 
the  card  for  the  user  to  "click  on"  with  n 
mouse,  invoking  a  procedure  which  can 
transfer  control  to  another  card  as  well 
ns  perform  any  number  of  housekeeping 
chores.  Clicking  on  the  mental  model 
button,  a  combined  text/graphlcnl 
description  of  the  package  appears  (figure 
2).  The  purpose  of  this  information  is  to 
give  the  user  a  quick  and  dirty  feel  for 
the  overall  behavior  of  the  package.  It 
is  a  rough  sketch  of  package  semantics. 

The  Ada  spec,  button  leads  the  user 
to  a  syntactic  description  of  the  package 
interface  (figure  3).  This  is  a  minimal, 
compiler  readable  form  of  the  interface, 
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providing  semantics  only  In  the  form  of 
operation  names,  formal  parameter  names 
and  types,  and  exception  names.  Notice 
that  HyperCard  allows  for  the  creation  of 
scrollable  fields,  as  shown  by  the  scroll 
bar  to  the  right  of  specification. 

the  informal  spec,  button  leads  to  an 
Ada  specification  annotated  with  english 
language  seaantic  descriptions  in  a  fora 
similar  to  that  used  by  Cutcag  and  llskov 
in  (3)  (figure  A).  From  the  effects 
clause  of  the  Af)9  operation,  we  see  that  a 
vertex  is  created,  an  input  itea  is  placed 
"In"  the  vertex,  and  the  vortex  la  added 
to  the  graph.  The  restraints  clause 
defines  any  requirements  on  the  input 
parameters,  the  modifies  clause  defines 
which  if  any  of  the  input  parnaeters  are 
modified  on  procedure  completion,  and  the 
exceptions  clause  defines  the  Ada 
exceptions  that  night  be  raised  by  the 
procedure  along  with  the  abnormal  effects 
of  the  procedure  If  such  exceptions  are 
raised. 

The  Formal  spec,  button  loads  to  a 
formal  larch-like  (5J  Interface 
specification  (figure  5).  The  semantics 
of  this  specification  are  defined  in  terms 
of  an  algebraic  model  of  graph  semantics, 
accessed  through  the  Formal  model  button 
(figure  6).  This  two-tiered  approach  to 
describing  abstract  data  type  behavior  is 
useful  In  that  it  allows  for  the 
separation  of  language  specific  features 
such  as  procedure  side  effects  and 
exceptions  from  language  independent 
semantic  descriptions  written  in  a 
straightforward  functional  style. 

In  addition  to  the  buttons  leading  to 
overall  semantic  descriptions,  there  is  a 
button  leading  to  a  Justification  of 
specification  syntax,  and  a  button  lending 
to  a  description  of  the  operations  in  the 
Intorfoce  that  collectively  fort;  on 
iterator.  The  justification  description 
includes  a  rational  for  why  this 
particular  syntax  was  chosen  along  with 
examples  of  ocher  possible  forms  chat 
could  have  been  chosen.  In  our  pnrcicular 
prototype  the  iterator  button  lends  to  a 
single  card  describing  the  Iterator 
operations  and  presenting  a  graphical  view 
of  the  iterator.  It  is  important  to  note 
however  that  the  flexibility  of  HyperCard 
would  allow  us  to  represent  the  Iterator 
by  yet  another  "web"  card  containing 
buttons  leading  to  o  different  attribute 
of  the  iterator. 

The  remaining  buttons  arc  traversal 
buttons,  i.c.,  they  aid  the  user  in  moving 
to  related  "web"  cazdu.  The  Graphs  button 
leads  back  to  the  Graph  class  state  window 
(see  taxonomies  sections),  from  which  the 
user  can  choose  another  graph  and  begin 
the  exploration  process  anew.  The  Usage 


and  Implementation  arrow  buttons  lead  the 
user  to  web  cards  for  the  respective 
information. 


Implementation  Information 

The  implementation  is  the 
satisfaction  of  the  specif icmtlon 
contract,  and  the  user  needs  to  be 
comfortable  that  It  Indeed  accomplishes 
its  goal.  In  addition,  the  state  of  the 
are  In  specification  is  such  chat  the 
implementation  must  be  there  to  "fill  In 
the  blanks".  This  Information  might 
Include  a  properly  structured  and 
annotated  Ada  body,  module  design 
information,  a  mental  model  of 
Implementation  structures,  veriflcntion 
information,  and  implementation  tradeoffs. 

Consider  the  web  of  implementation 
information  for  the  graph  specification 
described  in  the  previous  section  (figure 
7).  This  implementation  web  includes  both 
english  language  and  graphical 
descriptions  of  the  representation  of  a 
graph,  an  Ada  body,  the  Ada  private  part 
of  the  specification,  verification  and 
test  plan  information,  the  resources  used 
by  the  Implementation,  and  a  Justification 
of  the  package  implementation  design. 
Notice  chat  the  Ada  private  part,  alchough 
physically  in  the  package  specification, 
is  actually  part  of  the  Implementation, 
and  should  be  treated  as  such.  This  Is 
not  really  a  problem,  as  environment  cools 
can  present  two  different  views  of  an  Ada 
package  specification,  one  containing  the 
private  part  for  the  compiler,  and  cho 
other  minus  the  private  part  for  the  user. 


Usage  Information 

Usage  information  Is  an  extension  of 
the  specification  semantics.  In  the  case 
of  complex  interfaces,  the  user  needs  to 
undorstond  how  the  functionality  of  n 
component  can  be  combined  to  construct  a 
complex  application. 

As  mentioned  earlier,  a  specification 
is  n  contract  between  the  user  nnd 
implementor  of  a  component.  Complicating 
matters  here  is  the  promotion  of  reuse  as 
a  software  engineering  soal.  Clearly  u 
specification  needs  to  be  designed  with  n 
class  of  users  in  mind  rather  than  just  a 
single  user.  The  usage  information 
supplied  for  a  particular  component 
therefore  should  contain  not  only  specific 
examples  of  component  usage,  but  also  the 
characteristics  of  the  class,  or  domain, 
of  users  that  enn  use  the  component,  and 
general  patterns  of  usage  within  this 
domain . 
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Tho  above  information  is  to  n  great 
extent  domain  specific,  and  it  is  not 
entirely  clear  to  us  how  much  indorsation 
to  supply  for  a  general  purpose  "conpucer 
science  domain"  package  such  as  Graph. 

For  our  prototype  system  we  have  provided 
a  number  of  examples,  including  one  for  a 
PERT  chart  (figure  8),  ss  well  as  general 
patterns  of  Graph  usage  as  typically 
presented  in  good  data  structures  texts. 


Represent  inn  Taxonomic,  Structures: 

In  addition  to  describing  component 
information  webs,  hypertext  hns  proven 
useful  for  describing  tnxononic  structures 
of  components,  ns  well  ss  information 
associated  with  component  classes.  Fur 
example,  the  class  state  window  in  figure 
9  is  used  to  access  the  class  of  graph 
cooponents  in  the  Hooch  library. 

The  current  "scocc"  of  this  card  is 
of  an  undirected  unbounded  unmanaged 
graph.  In  this  state  the  Info  web  button 
loads  to  the  associated  component 
specification  information  web. 

To  change  the  cord  state,  the  user 
needs  simply  to  click  on  (this 
highlighting)  the  Change  state  button, 
followed  by  nny  combination  of  the 
Directed,  Bounded,  and  Managed  buttons. 

The  Modules  button  loads  to  a  card 
describing  n  broad  class  of  computer 
sclonce  modules  in  the  Booch  cooponents, 
Including  the  Graph  class  in  particular. 
The  ?  button  nl lows  tho  user  to  exit  tho 
HyperCard  application  to  start  anew. 

"Meta-information"  about  Che  taxonomy 
Itself  is  important  for  beginning  users  of 
Che  taxonomy.  When  the  Change  state 
button  is  in  non-highllghted  mode,  the 
user  con  click  on  any  node  in  the  tree  and 
get  information  nbout  Che  meaning  of  chat 
node.  Specifically,  Che  Craph  button 
leads  to  a  class  Information  web, 
discussed  in  the  following  section. 


Exploring  Commonality 

As  we  have  constructed  knowledge  webs 
around  Che  individual  component  parts  of 
both  the  Booch  Components  and  CAHP  parrs, 
we  have  become  aware  of  a  great  deal  of 
information  shared  across  modules,  the 
sharing  corresponding  to  the 
classification  criteria  used  in  the 
taxonomies.  This  has  led  us  to  look  at 
the  relationships  across  information  webs 
within  various  conponcnt  taxonomies. 

Consider  the  following  exanples. 

Test  plans  and  test  drivers  are  similar 
across  classes  of  components  -  stacks, 


queues,  graphs,  etc.,  and  implementation 
models  are  vlmllnr  across  components  with 
the  same  form.  Algebraic  models  ore  also 
similar  across  classes  of  components  -  the 
sequence  being  a  possible  model  tor 
stacks,  queues,  deques,  etc. 

Recall  that  the  Graph  class  state 
window  contains  a  Craph  button.  Thu 
Intent  here  is  that  this  button  load  to  a 
class  information  web.  Tho  structure  of 
the  class  information  web  reflects  the 
similarities  between  the  individual 
information  webs  of  that  class.  For 
example,  tho  class  information  web 
contains  a  mental  model  button,  describing 
the  general  attribute-independent  model  of 
a  graph,  and  a  formal  model  button, 
describing  tho  formal  model  of  n  graph 
used  by  all  cooponents  of  chnt  class. 

Our  aim  hero  is  for  the  user  of  a 
taxonomy  to  be  able  to  extract  as  much 
information  as  is  possible  without  having 
to  commit  to  a  particular  component,  thus 
further  speeding  up  the  evaluation 
process. 


Shared  Resource  Webs 

In  nddition  to  exper imontlng  with 
class  Information  webs,  wo  have 
experimented  with  tying  component 
information  webs  to  information  webs  nbout 
n  particular  web  attribute.  One  aren  we 
ore  particularly  interested  in  is  formal 
specification. 

We  have  taken  the  Lurch  handbook  of 
algebraic  models  and  have  created  n 
hierarchically  structured  hypertext  web  of 
spocif lcocions,  including  sequences, 
graphs,  stacks,  etc.  We  have  then 
attached  component  information  webs  to 
this  specif icntlon  "database"  via  the 
formal  model  button.  Tho  user  enn  then 
access  the  formal  model  of  a  gruph  from 
this  shared  resource.  In  addition,  the 
backtracking  capability  of  HyperCard 
providos  a  trail  for  the  user  to  back  out 
through  er.ee  the  formal  model  web  is 
entered. 


Alternate  Taxonomic  Structures 


At  times  it  moy  be  valuable  to 
provide  alternate  access  to  n  collection 
of  modules  by  means  of  different  taxonomic 
structures.  For  example,  rather  than 
using  the  Booch  taxonomy  to  access  his 
components,  we  nay  prefer  to  use  che 
faceted  classification  method  of  Ruben 
Prieto-Diez  [8).  With  hypertext,  we  con 
provide  both  structures  in  a  single 
hypertext  web. 
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As  Mentioned  earlier,  we  have  also 
applied  Che  hypertext  model  to  the  CAHP 
(Common  Ada  Hlssllc  Packages)  components 
o £  HcDonnell-Douglns.  While  the  general 
CAHP  taxonomy  Is  a  fairly  rigid  hierarchy, 
as  pictured  In  Che  HyperCard  cord  of 
figure  10,  alternate  means  of  package 
access  exist.  Specifically,  an  expert 
system  has  been  developed  by  McDonnell- 
Douglns  where,  through  a  series  of 
questions  and  answers,  the  user  1s  led  to 
proper  choice  of  a  component  In  the 
collection.  Hypertext  can  be  used  as  Che 
Information  structuring  language  In 
connection  with  such  a  system.  The  user 
then  has  a  choice  of  whether  to  be  guided 
to  a  choice  or  to  peruse  the  taxonomy 
Independently. 


Hypertext  Systems  ns  Applications  Generntors 

A  number  of  hypertext  systems, 

HyperCard  Included,  contain  a  rich  3ct  of 
tools  for  prototyping  user  Interfaces.  It 
was  for  this  reoson  that  we  began 
experimenting  with  HyperCard.  Our 
Intention  was  originally  chat  HyperCard  be 
a  "stop-gap"  until  we  completed  our 
SccGraph  system,  but  hooks  In  HyperCard 
along  with  the  availability  of  Maclntosh- 
DEC  Interfaces  make  a  full-scale  library 
system  with  a  HyperCard  front-end 
feasible. 

HyperCard,  with  Its  flexible  graphics 
editor,  script  language,  and  built-in 
facility  to  create  "stocks"  of  cards, 
contributes  slgnif lcontly  to  reuse.  A 
number  of  Application  Generation  cools 
3uch  03  this  one  exist  under  the  headings 
of  CASE  tools,  4GI.s,  UNIX  cools,  etc., 
and  it  Is  In  those  areas  that  we  arc 
making  great  strides  in  reuse.  As  with 
the  accessibility  of  component  libraries 
described  earlier,  understanding  Is  the 
key  Issue.  Whether  we  provide  parts  for 
systems  designers  to  compose  systems  or 
application  generators  to  generate 
systems,  the  designers  must  be  provided 
with  a  cleor  understanding  of  what  Is 
provided.  This  Is  a  noble  goal  that  is 
rarely  achieved. 


Summory 

Our  premise  in  this  paper  Is  that 
understanding  is  the  primary  Inhibitor  to 
the  reuse  of  software  components.  We  have 
used  the  hypertext  model  to  describe 
information  webs  of  components, 
collections  of  interrelated  component 
attributes  that  we  argue  collectively 
define  a  component. 

A  number  of  interesting  uses  of 
hypertext  emerged  from  the  construction  of 
the  above  webs.  We  recognized  that  we 


could  construct  'and  describe  taxonomic 
structures  of  component  collections  using 
the  same  hyperenrd  model  os  we  used  to 
describe  the  components  themselves.  In 
addition,  we  could  easily  construct 
alternate  taxonomic  structures  for  the 
same  component  collection,  class 
Information  webs  representing  classes  of 
component  information  webs,  and  shared 
resource  wcb3  describing  "databases"  of 
information  for  each  component  Information 
web  attribute. 

A  large  part  of  constructing  the 
Information  webs  for  component  libraries 
such  ns  those  described  In  this  paper  Is 
tedious  work.  We  have  made  nn  effort  to 
fill  out  the  webs  for  both  the  Dooch  and 
CAHP  nodules  In  a  wny  that  "proves  the 
concept",  but  much  work  needs  to  be  done 
to  complete  the  project.  A  good  deal  of 
information  already  stored  is  repetitive 
and  needs  to  be  consistency  checked,  and  a 
good  deal  of  study  neods  to  be  done  to 
eliminate  existing  redundancy.  We  are 
currently  looking  toward  techniques 
developed  In  the  object-oriented 
programming  world  to  restructure  our 
library  components  in  this  regard. 
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Summary 

Many  DoD  systems  have  bean  developed 
using  reusable  software  parts.  Conversely, 
embedded  real-time  systems,  have  been 
developed  with  a  minimum  of  software  re¬ 
use.  The  inherent  difficulties  in  develop¬ 
ing  reusable  parts  for  embedded  real-time 
systems  result  from  critical  timing  con¬ 
straints  or  dependencies  on  processing 
resources.  To  overcome  these  difficulties, 
an  aggressive  policy  for  part  reuse  must 
be  practiced  throughout  the  software  de¬ 
velopment  lifecycle.  This  paper  identifies 
issues  in  writing  reusable  parts  within 
the  conceptual  fromawork  of  real-time 
programming.  A  programming  discipline  is 
proposed  that  would  be  based  upon  guide¬ 
lines,  paradigms,  and  uniformity  of  Ada 
runtime  systems. 

Key  Words.  Ada,  real-time  programming, 
software  reuse. 


Background 

The  numbar  of  Department  of  Defense 
(DoD)  applications  using  the  Ada  languago 
is  increasing  rapidly  fostered  by  the 
availability  of  over  200  base  and  derived 
validated  compilers  covering  a  broad  spec¬ 
trum  of  computers.  Reports  documenting 
these  applications  indicate  that  many  have 
been  successfully  developed  either  using 
reusable  parts  or  having  yielded  reusable 
parts.  In  addition,  specific  applications 
have  boon  targeted  to  demonstrate  the 
efficacy  of  reusing  Ada  parts  for  embedded 
roal-timo  DoD  applications,  nomoly,  the 
Common  Ada  Missile  Package! .  To  date, 
embedded  real-time  DoD  applications  have 
not  achieved  a  high  degroo  of  part  rouao 
because  of  the  difficulty  of  developing 
reusable  Ada  code  that  must  satisfy  hard 
real-time  constraints  intrinsic  to 
deadline-driven  systems.  This  difficulty 


is  compounded  by  the  emerging  use  of 
multiple  computers  to  achieve  parallel 
program  execution  within  embedded  real¬ 
time  applications. 

A  significant  amount  of  material  has 
been  contributed  to  the  literature  on 
developing  reusable  Ada  parts2.  This 
material  has  included  guidelines  and 
paradigms  for  both  design  and  coding; 
howovar,  there  has  boon  limited  attention 
to  part  performance  efficiency  and  real¬ 
time  constraints.  The  exception  has  been 
recognising  that  performance  enhancing 
dependencies  upon  the  individual 
execution-time  behavior  of  Ada  runtime 
systems  oust  bo  avoided  when  developing 
parts  for  mission  critical  computor 
resource  applications2. 

Thin  paper  focuses  upon  issuos  that 
must  be  addressed  by  a  discipline  for 
reusable  Ada  programming  in  roal-timo 
applications.  This  discipline  combinco 
current  Ada  reusability  programming 
practices  with  techniques  that  remove  some 
of  the  program  execution  unpredictability 
that  can  thwart  writing  programs  for  roal- 
timo  applications.  In  addition,  the 
discipline  promotes  deducing  a  program's 
validity  from  its  static  text.  Programs 
ara  designed  based  upon  a  precise 
specification  of  the  execution  time 
constraints  of  the  application  together 
with  an  understanding  of  the  impact  of  the 
Ada  runtime  system  on  software  rouso*!. 

Initially,  the  paper  presents  a  brief 
discussion  of  tho  conflicts  and 
difficulties  of  writing  reusable  real-timo 
Ada  softw&ro.  Tho  discussion  providos  a 
context  for  bounding  tho  issues  that  arise 
from  translating  into  Ada  a  simple 
paradigm  frequently  used  by  real-time 
applications.  Finally,  tho  paper  outlines 
a  proposal  for  introducing  a  discipline  to 
practicing  programmers. 
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Conflict*  and.  Dif f iculties 

Explicit  in  tho  design  goals  for  the 
Ada  language  was  a  desire  to  reduce  the 
cost  of  writing  embedded  real-time 
application  software.  Tho  language's 
ability  to  compose  an  application  from 
independently  produced  software  implicitly 
advocates  software  reuse  as  a  significant 
contribution  towards  achieving  this  goal. 
Unfortunately,  tho  availability  of  a 
programming  language,  however  rich  in 
abstractions  for  software  reuse,  is 
insufficient  to  guarantee  reusable  code. 
The  ln>’  of  guaranteed  reusability  is 
particularly  evident  once  adherence  to 
execution  time  independence  is  compromised 
by  assumed  explicit  or  implicit  processing 
resources.  In  the  prasence  of  hard  real- 
time  constraints,  execution  time 
dependencies  must  be  reconciled  with 
software  reuse,  thereby  presenting 
numerous  conflicts  and  difficulties.  Thoso 
conflicts  and  difficulties  can  be 
ameliorated  only  through  disciplined 
programming  that  carefully  legislates 
against  the  uncontrolled  use  of 
implementation  dependencies  that  bound  the 
semantic  fringes  of  the  language. 

Real-Time  Software. 

Real-timo  software  generally  refers  to 
software  parts  whore  correctness  depends 
upon  timing  constraints  over  which  there 
may  bo  little  or  no  programmatic  control. 
For  example,  a  part  must  meet  a  hard 
deadline  or  else  it  is  in  a  failure  modo. 
Often  these  dependencies  aro  associated 
with  controlling  or  monitoring  external 
devices  whose  successful  operational 
performance  is  time  critical.  These 
dependencies  load  to  several 
distinguishing  features  that  may  be  used 
to  characterise  real-timo  software.  Among 
these  featuros  aro  concurrent  execution, 
event  synchronisation,  fault  tolerant 
execution,  and  low-level  hardware 
interaction.  In  this  paper,  concurrent 
execution  and  event  synchronisation  are 
considered  the  features  that  frequently 
dominate  the  design  and  coding  of  real¬ 
time  programs,  which  in  turn,  compromise 
the  reusability  of  its  constituent  parts. 

Concurrent  Execution.  A  principal 
reason  for  concurrent  execution  is  to 
decroase  tho  execution  time  of  a  program. 
Parts  of  a  program  may  oxocute  on 
different  processors  or  may  share  a  singla 
processor.  Consequently,  the  partitioning 
of  an  application  for  concurrent  execution 
requires  tho  careful  analysis  of  part 


dependencies  to  ensure  the  optimal 
utilization  of  processing  resources. 
Traditionally,  tho  predominance  of  singlo 
processor  computers  has  permitted  only  the 
logically  concurrent  oxocution  of 
programs.  Tho  scheduling  of  processing 
resources,  or  processor  sharing,  among 
program  parts  has  become  an  important 
dimension  of  design  and  coding  real-timo 
programs.  While  multiprocessor  computers 
and  multicomputers  aro  now  commonplace, 
many  applications  do  not  have  sufficient 
resources  to  avoid  somo  degree  of 
logically  concurrent  execution.  In 
addition,  thera  are  often  instances  where 
logically  concurrent  execution  may  bo 
advantageous  when  physically  concurrent 
execution  incurs  substantial  penalties  in 
sharing  data  among  tho  parts  rosidont  on 
remote  computers.  Therefore,  scheduling 
processing  resources  in  real-time 
programming  will  continue  to  complicate 
part  reuse. 

Event  Synchronisation.  Event  synchro¬ 
nization  allows  program  execution  to  be 
formulated  with  raspect  to  a  consistent 
specification  of  a  part's  timing 
dependencies  through  a  uniform  abstraction 
of  time.  When  tho  timing  dependencies  are 
not  predictable,  i.e.,  ovonts  are 
asynchronous,  concurrent  execution  of  a 
part  is  commonly  employed  to  achieve  the 
necessary  event  synchronization  for 
correct  program  execution.  Real-time 
applications  often  comprise  parts  whoso 
execution  is  referred  to  as  periodic, 
aperiodic,  or  sporadic.  These  applications 
have  requirements  for  synchronizing  with 
differing  avents,  e.g.,  an  internal  clock 
tick,  a  signal  from  an  extornal  dovico,  or 
exchanging  messages  among  concurrently 
executing  parts. 

Ada  Real-Time  Model. 

In  Ada  a  unified  approach  to 
concurrent  execution  and  event 
synchronization  is  specified  through  the 
Ada  tasking  model.  Whilo  tho  model 
provides  potentially  reusable  abstractions 
for  concurrent  execution  and  event 
synchronization,  it  has  been  the  subject 
of  intensive  debate  when  applied  to  real- 
timo  applications^.  Three  key  issues 
become  npparent  when  writing  rouoable  Ada 
real-timo  parts.  These  aro  briefly 
addressed  in  the  following  paragraphs  with 
regards  to  justifying  a  programming 
discipline. 

Abstraction ■  Tho  Ada  tasking  model 
supports  abstractions  for  the  asymmetric 
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communication  and  synchronisation  among 
autonomous  parallel  threads  of  control 
within  a  single  program.  The  abstractions 
can  bo  used  to  express  many  classical 
paradigms  that  protect  shared  data  and 
mossage  passing  with  minimal  regard  to  the 
underlying  processing  resources  available. 
Whilo  this  level  of  abstraction  may  be 
perceived  as  promoting  software  reuse,  it 
can  be  a  disadvantage  when  writing  parts 
subject  to  critical  timing  constraints. 

Disadvantages  result  from  the 
unintentional  misuse  of  abstractions  and 
increased  semantic  complexity  introduced 
into  a  part  whenover  concurrency  and 
synchronization  constructs  are  integrated 
within  a  programming  language.  For 
examplo,  timing  anomalies  can  typically, 
but  surprisingly,  occur  when  insufficient 
attention  is  given  to  task  activation  and 
task  termination.  This  type  of  problem  may 
be  obviated  by  guidelines  that  recognize 
tho  program-wide  implications  of  the 
abstractions.  A  moro  difficult  problom  is 
manifested  when  arcano  use  of  the 
abstractions  becomes  necessary  to  program 
commonly  accepted  roal-timo  processing 
models.  For  example,  tho  partitioning  of  a 
program  for  distributed  execution  remains 
unspecified  within  tho  tasking  model  and 
loads  to  a  diversity  of  execution  models 
that  are  not  conducive  to  writing  reusable 
parts.  Therefore,  it  bocomoo  nocoonary  to 
adopt  rules  tiiat  facilitate  tho 
composition  of  distributed  programs  from 
artificially  constructed  abstractions  or 
paradigms. 

Eventual  resolution  of  those  kind  of 
problems  may  requira  specification  of 
carefully  defined  auxiliary  abstractions 
that  complement  tho  oxinting  Ada  tasking 
model®.  The  auxiliary  abstractions  would 
be  used  to  construct  reusable  packages 
that  implement  common  roal-time  processing 
models. 

Dependencies.  Tho  abstraction  of 
concurrent  execution  and  ovent 
synchronization  into  tho  Ada  tasking  model 
would  seem  to  remove  many  of  tho 
transportability  obstacles  to  reusing 
parts  from  applications  that  have 
traditionally  dopondod  upon  specialized 
roal-timo  oxocutivos.  Howovor,  when 
critical  timing  constraints  are  present, 
parts  may  bocomo  dependent  upon  specific 
implementation  options  permitted  by  the 
model  or  upon  constructs  having  implied 
temporal  semantics.  For  example,  a  delay 
of  zoro  may  precipitate  an  opportunity  for 
task  rescheduling,  i.o.,  synchronizing  a 


scheduling  ovent.  However,  reusable  parts 
should  not  rely  upon  a  delay  of  zoro  to 
affect  task  rescheduling  given  tho  current 
lack  of  uniformity  among  implementations 
of  Ada  runtimo  systems.  An  implementation 
may  treat  this  abstraction  as  a  null 
construct  and  continue  execution  of  the 
enclosing  part. 

It  has  boon  recognized  that  a  program 
enclosing  reusable  parts  must  exhibit 
functionally  identical  execution  when 
transported  among  different  execution 
environments?.  A  corollary  of  this  would 
advise  against  relying  upon  tho 
functionally  equivalent  execution 
guaranteed  by  the  Ada  standard  when  parts 
of  a  program  are  to  bo  widely  reused. 
However,  even  this  desidoratum  cannot 
guarantee  successful  part  reuse, 
particularly  among  roal-timo  applications 
whore  there  is  a  propensity  to  exploit 
language  features.  For  example,  in  the 
instance  whoro  two  parts  are  combined  from 
different  programs,  tho  existence  of 
implicit,  but  conflicting,  runtimo  system 
dependencies  would  result  in  aberrant 
execution  behavior. 

While  tho  prohibition  of  many 
implementation  dependencies  must  be 
includad  in  tho  programming  discipline, 
relaxation  of  the  prohibition  may  bo 
essential  in  order  to  achieve  predictable 
and  reusable  execution  behavior.  The 
relaxation  would  most  likoly  occur  whoro 
rousablo  paradigms  are  provided  that 
stipulate  implementation  characteristics 
based  upon  formal  analysis  of  tho  critical 
timing  constraints. 

Performance .  Tho  production  of 
reusable  software  can  bo  achievod  only 
through  moro  intollectunlly-intcnsive 
software  development  practices  and  by 
sacrificing  somo  dogroo  of  performance 
efficiency.  For  roal-timo  applications  the 
tradeoff  botwoon  reusability  and 
performance  efficiency  is  a  dominant 
issue,  especially  in  tho  prasonco  of 
scheduling  shared  resources.  The  semantic 
ologanca  and  versatility  of  tho  Ada 
tasking  abstractions  may  impose  both 
execution  and  storngc  penalties  upon  an 
application  that  aro  not  competitive  with 
those  imposed  by  a  compact  rudimentary 
roal-timo  executive  kernel. 

In  many  instances,  variations  in 
performance  efficiency  may  depend  upon  tho 
individual  runtime  system  implementation. 
However,  variations  may  result  from  the 
design  and  implementation  strategies 
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selected  for  tin  application.  Consequently, 
the  programming  discipline  must  provide 
sufficient  guidauca  so  that  strict 
adherence  to  Ada  reusability  rubrics  does 
not  overwhelm  the  actual  functional 
processing  of  a  part.  For  example,  a 
reusable  part  that  implements  a 
computational  intensive  algorithm  required 
to  perform  frequent  numeric  conversions  to 
accommodate  different  numeric  typos,  will 
bo  reused  only  if  the  conversion  execution 
costs  are  insignificant  compared  to  the 
actual  computations.  In  addition,  the 
discipline  should  rocognizo  the  effects  of 
compilation  techniques  that  offer  the 
opportunity  for  variations  in  performance 
efficiency.  The  performance  efficiency  of 
using  dynamic  arrays  in  unconstrained 
record  typos  can  differ  significantly 
among  implementations  and  typifies  a 
common  construction  warranting  attention 
and  evaluation  when  used  in  a  reusable 
part. 

A  Disciplined  Approach 

A  discipline  for  real-time  programming 
was  advocated  in  a  paper  by  Nicklaus 
Wlrth^  The  meti’  -ion  for  the  discipline 
was  to  provido  a  straightforward  approach 
toward  analytically  verifying  the 
reliability  of  real-time  programs.  In 
order  to  support  the  discipline,  the  use 
of  suitable  abstractions  for  oxprossing 
concurrent  program  execution  and 
synchronization  was  deemed  essential  to 
minimize  dependencies  upon  processing 
spood.  Through  those  abstractions  logical 
assertions  would  allow  tho  validity  of  a 
program  to  be  deduced  from  tho  program’s 
text  with  the  same  assurance  as  for  a 
serially  executed  progrnm.  Such  a 
discipline  would  increase  tho  potential 
for  software  rouse. 

Tho  essence  of  the  proposed  discipline 
is  that  the  reasoning  and  facilities  for 
real-time  programming  should  be  limited 
extensions  to  those  supporting 
multiprogramming  which,  in  turn,  should  bu 
limited  extensions  to  those  used  for 
sequential  programming.  Tho  important 
contribution  of  tho  discipline  is  managing 
the  complexity  of  real-time  constraints  in 
tho  presence  of  processor  sharing.  Tho 
discipline  requires  that  processor  sharing 
bo  ignored  in  assertions  of  tho  part’s 
computational  stato  and  confined  to 
analyzable  timing  considerations  of 
processor  utilization. 

Finally,  the  discipline  should  bo 
decisively  shaped  by  the  programming 


language.  In  this  paper,  tho  discipline  in 
shaped  by  Ada,  its  runtime  system,  and 
toilets  for  software  rouse. 

Fundamentals . 

Tho  fundamentals  of  disciplined 
reusable  Ada  programming  for  real-time 
applications  adapt  the  principles  of 
Wirth's  discipline  to  programming 
practices  for  achieving  software  rouoo. 
Conflicts  between  expressing  time- 
dependent  execution  behavior  and  writing 
reusable  code  must  be  reconciled. 
Reconciliation  compromises  part 
reusability  to  the  extent  that  only 
limited  reusability  is  achievable  in  the 
presence  of  critical  hard  timing 
constraints.  At  a  minimum,  tho  design  for 
tho  part  should  be  reusablo  if  part 
reusability  is  claimed. 

The  formulation  of  binary  and  general 
semaphores  has  boon  used  by  Wirth  to 
illustrate  implicit  timo  dependencies  that 
may  occur  in  the  simplest  of  real-time 
applications.  While  the  dangers  of  using 
tiiese  paradigms  have  boon  citcdO  to  argue 
for  tiie  safety  of  tho  Ada  rendezvous, 
their  use  in  real-timo  applications  is 
frequently  necessary  for  nfficieney,  since 
their  analogues  are  commonly  supported  by 
the  processing  resourco.  Therefore,  they 
provide  a  pedagogical  example  of  how  to 
apply  some  of  the  fundamentals  of  a 
discipline  when  adapted  to  Ada. 

Recent  work  has  indicated  that  even 
such  classical  paradigms  are  not  without 
flawslO  unless  roused  undor  execution 
environments  where  the  timing  dependencies 
are  well-defined.  Therefore,  wary  of  this 
admonition,  a  general  semaphore  is 
constructed  from  two  binary  semaphores  by 
directly  translating  (reusing)  a  correct 
implementation  of  the  paradigmll  to  Ada. 
The  ganorai  semaphores  is  then  transformed 
into  a  reusable  Ada  part  which  is 
critiquad  with  respect  to  its  use  for 
real-time  applications.  Finally,  tho 
difficulty  of  instrumenting  tho  part  for 
raal-tima  use  is  presented. 

Programming  for  Rouse. 

General  tenets  for  programming 
reusable  Ada  parts  have  been  described  in 
tho  litoraturol2.  In  addition,  criteria 
for  reusability  have  boon  defined  that 
qualify  a  part  as  weakly,  effectively,  or 
strongly  reusable?.  Weakly  reusable  parts 
require  extensive  source  modifications  and 
have  limited  application;  strongly 
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rousnblo  parts  require  minimal  source 
modifications  anti  have  widespread 
application.  In  this  paper,  programming 
efie ctlvely  reusable  parts  is  emphasised. 
These  parts  possess  a  high  pragmatic 
potential  lor  reuse. 

iilnary  Semaphore.  A  binary  semaphore 
to  protect  critical" regions  of  code  may  be 
implemented  in  Ada  using  a  trivial  server 
task  type  IdiomO.  The  following  two 
variations  provide  for  the  binary 
semaphore  to  have  either  a  "locked"  or 
"unlocked"  condition  initially.  The 
semaphore  is  constructed  as  an  abstract 
type  encapsulated  in  a  simple  package  that 
provides  an  Interface  specification 
reflecting  the  accepted  notation  for 
binary  semaphore  operations.  A  task  typo 
is  reused  to  achieve  the  different  initial 
conditions. 


pockopa  *ln»ry  Sa-aphora  Packaga  I* 

Lachad  ilnary  Sa-aphara  Typa 

la  llalM  prlvata; 

Um  Unlachad  IlMry.StMrtiir*  Tp< 

la  ll-ltad  prlvata; 

pracadvra  P  (Sana  I  In  UcVal.llnirif.Sm^tra.Tpa) | 
pracadara  V  (Sana  I  In  Lackad.Btnary  Sa-aphora  Tpa}| 
pracadara  P  (Sana  t  In 

Unlachad  Binary  Sa— aphyra  Typa); 
pracadara  V  (Sana  I  In 

UnlacVad.Binary  Saaipir«.Tna)| 
prap-a  If*.  I  HE  (P,  V)  j 
prlvata 

took  typa  Unlochad.Blnary,  Sa-aphara  Typa  la 
antry  P  Vi 
antry  V  P| 

and  Unlachad  Binary. Sa-aphara  Typa; 
typa  ladia(  Binary  Sa-aphara  Typo 

la  na*  Unlachad  Binary. Sa-aphara  Typa; 
and  Binary  Saawphara  Packaga; 
packaga  Wady  Binary  Soaaphara  Packaga  la 
katk  My  Unlechad.Blnary.Sa-aphtra Typa  la 
Wagln 
'•♦P 

accapt  P  V| 
accapi  V.P; 
aa(  laapj 

and  thlochad  61nary.Sa-nphrra.Typa; 
pracadara  P  (Sana  i  In 

Lackad.Blnary.Sa-aphora.Typa)  la 

Wag  In 

Saw.*  P{ 
and  0; 

pracadura  V  (Sana  I  In 

Uockad.Blnary.Sa-aphgra.Typa)  la 

Wagln 

Sa-a.P  V] 
and  V| 

pracadura  P  (Sana  i  In 

Unlocked. Binary. Sa-aphora. Typa)  la 

Wagln 

Saaw.P.V; 

and  Pi 

pracadura  V  (Sana  i  In 

Unlocked  Binary  So— ephore.Type)  la 

Wagln 

So-o.V.P; 
and  Vi 

and  Blntry.Se-ephoro.Pockoge; 

The  above  package  illustrates,  upon 
initial  inspection,  a  reusable 
implementation  for  binary  semaphores. 
However,  it  is  likely  that  for  real-time 
applications,  performance  considerations 


would  substantially  reduce  its  utility 
unless  the  server  task  typo  idiom  was 
appropriately  optimised  to  minimise  the 
normal  overhead  associated  with  a  task 
entry  call.  In  addition,  this  particular 
task  idiom  fails  to  provide  a  suitable 
method  for  self-termination  of  the  task, 
thuroby,  requiring  some  external  action, 
vis.,  an  abort,  to  be  employed.  The  idiom 
can  be  modified  to  enclose  the  accept 
statements’  within  a  select  statement  that 
includes  a  terminate  alternative,  but  this 
would  most  likely  increase  overhead.  Un¬ 
derstanding  these  limitations  the  abstrac¬ 
tion  may  be  reused  to  construct  a  general, 
or  integer,  semaphore. 

Cnneral  Semaphore.  A  general  semaphore 
is  constructeel  as  the  following  abstract 
type  encapsulated  in  a  generic  packago 
using  the  binary  semaphore  package.  Again, 
the  interface  specification  reflects  the 
accepted  notation  for  general  semaphore 
operations. 


»Hh  Binary  Sa-aphoraPachyga; 
ga  narlc 

typa  Sa-aphora  Count  Typo  la  rang*  Ol 
packaga  Canaral  Sa-aphora  Packaga  ta-plata  la 
typa  Canaral  {a— aphara  typa  la  flallad  privotai 
pracadara  P  (Saw*  I  In  aut  Canaral  Sa-aphora  Typa); 
pracadara  V  (3a— a  1  In  aai  Canaral  Sa-ophara  Typa); 
Sa-aphora. Error,  Invalid  Sa-aphara  I  exception; 
prlvaia 

aaa  Binary  Sa-aphara  Packaga; 
iypa  Canaral  So-ophore.Typa  la 
racard 

Wutoa  I  Unlocked  Blnory.Sa—aphoro. Typa; 

Wall  I  Lackad  Btnary.Seawphore.Type; 

Count  I  Sa-aphara.  Cauni  Typa 

la  Sa-aphara.Caunt.Typa'laal) 

and  racard; 

and  Canaral  3a— aphara  Packaga  Te-plate; 
packaga  Wady  Canaral  Sa-aphara  Packaga  To«plsto  la 
pracadara  P  (Sa—a  I  In  aai  Canaral. Sa-aphara  Typa)  la 

P  (Sa— 10. Wutoa) ; 

Sa«a, Count  |«  Sa—a. Caunt  -  1; 

If  Sa—a  Count  <  9  than 

V  (So— o. Wutoa) ; 

P  (Sa-a.Walt); 

and  If; 

V  (Sa—a .Wutoa) ; 

•acaptlan 

eh  on  Conatralnt  Error  a> 

V  (Sa—a .Wutoxj ;  ... 
ralaa  Sa-aphora  Error; 

and  P; 

pracadara  V  (Sa—a  l  In  out  Canaral  Sa-aphora. Typa)  la 

P  (So— o.Uutoa) ; 

So-o. Count  la  Sa— a.Count  a  1; 

If  Sa—a .Count  (a  ■  than 

V  (Sa-a.Walt); 

aloe 

V  (Sa— a.Wutaa) ; 
and  If; 
oicnatlan 

anon  Conatralnt. Error  a> 

V  (Somo.Uutoa);  ... 
roloa  Sa-aphora  Error; 

and  V; 

Wagln 

If  B  nat  In  Se-aphore_Count.Typa  than 
roloa  Invalid  3a«ophora; 
and  If; 

and  Canaral. So— ephoro.Packoge.Te-p lata; 
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Thtt  above  package  is  a  reusable  and 
safe  implementation  of  the  general 
semaphore.  It  provides  a  semaphore 
abstraction  that  may  be  used  to  create 
semaphores  of  differing  capacities,  i.o., 
eacli  semaphore  may  be  reserved  by  a 
different  number  of  clients.  The  formal 
generic  parameter,  Semaphore  Count  Type, 
specifies  limits  for  both  the  number  of 
clients  that  may  reserve  tho  semaphore, 
Semaphore.  Count_Type’Last,  and  for  tho 
number  o?  clients  that  may  bo  queued 
waiting  to  reserve  the  semaphore, 
Scmaphore^Count^Type'First.  Through  the 
use  of  a  "general  semaphore,  access  to  a 
shared  resource  may  be  controlled  by 
restricting  the  number  of  concurrent 
clients.  When  tho  semaphore  has  reached 
its  specified  capacity,  subsequent  clients 
are  required  to  wait  until  a  reservation 
is  released.  For  example,  in  tho  following 
code  fragments  two  semaphores  are 
declared;  one  is  equivalent  to  a  binary 
semaphore  and  tho  other  allows  a  maximum 
of  three  client  parts  to  reserve  tho 
semaphore. 

nktyH  Binary  Ceunt  Subtype 

la  Integer  ran**  -Naa  <}ueue_SI  la.  .1  j 

package  Binary  Smyhira  Package  la  ma 

Cenerel  Semephere.Peckefe  Template 
(Smikara.Cnint  Type  a) 

Binary  Count  Subtype) I 
uee  Binary. Semaphore.  Package; 

Binary  Semaphore  I  General. Semaphore  Type} 

subtype  Quertarnary  Ceunt.Subtype 

la  Integer  raaga  -Mea_queue.Sl je. .J) 

packaga  quarternery.Semephore.Package  la  naa 

Cenersl.Semephore.Package  Template 
(Semaphore. Count  Type  a) 
quaternary  Count  Subtype) | 
uaa  querternery  Semaphere  Packaga; 

quarternary. Semaphore  I  General. Semephere.Type; 

From  a.  performance  efficiency 
perspective  the  implementation  may  be 
unsuitable  for  sovoral  reasons.  The  most 
compelling  reason  i»  the  necessity  for  two 
tasks  to  service  the  binary  semaphores; 
even  in  the  presence  of  task 
optimizations,  tho  efficiency  of  the 
abstraction  is  likely  to  be  compromised. 
Also,  it  is  dubious  that  the  ability  to 
"inline"  procedures  will  necessarily 
improve  efficiency  given  that  tho 
subprogram  bodies  are  nontrivial  and  rely 
upon  exception  handlers  to  control  misuse 
of  the  abstraction. 

Programming  for  Performance. 

Programming  practices  to  increase 
performance  efficiency  vary  with  a 
particular  language.  These  practices 


enable  parts  to  be  optimized  for  minimal 
execution  time  or  economical  utilization 
of  storage.  Understanding  tho  relative 
efficiency  of  programming  constructs  is 
important.  A  construct  that  contributes  to 
the  generalization  of  a  part  may  incur 
unacceptable  execution  time  or  storage 
penalties  for  roal-time  applications. 

While  a  programming  discipline  must 
not  eschew  performance  efficiency,  striv¬ 
ing  for  optimal  performance  of  a  part  does 
not  guarantee  its  successful  rouse  for 
real-time  applications.  Finally,  a  disci¬ 
pline  must  carefully  delineate  between 
programming  optimizations  and  coda  optimi¬ 
zations  when  striving  for  performance 
efficiency.  Code  optimizations  are  likely 
to  compromise  part  reuse  and  are  inappro¬ 
priate  to  a  discipline. 

Refined  General  Semaphore .  A  refined 
generaf  semaphore  that  addresses  some  of 
the  criticisms  associated  with  an  exact 
Ada  transformation  of  the  paradigm  is 
achievad  by  improved  utilization  of  the 
Ada  tasking  model.  The  semaphore  is  con¬ 
structed  using  an  abstract  type  encapsula¬ 
ted  in  a  generic  package  using  an  equiva¬ 
lent  interface  specification. 


generic 

type  Semaphore.Ceunt.Type  le  reege  <>i 
geckege  Ada  Samephtre.Peckege.Templete  le 

Iyge  General  Semephere.Type  la  Halted  private; 
precedure  f  (See#  I  In  General  Semephere  Type); 
precedure  V  (Sena  I  In  CenerallSeaMphere  Type); 
prep..  INLINE  (P,  V) J 

Semsphere.Error,  Inva I Id.Samephera  i  eacepklen; 

grlvake 

keek  type  Genera I.Semephere.Jype  la 
enkry  ?; 
enkry  V; 

end  Cenerel  Semephere.Type; 
end  Ade.Semephore  Package  Template; 
package  kedy  Ade.Semephore.Packege.TempIste  la 
teak  bedy  Canaral  Semaphore  Tyga  Is 

Gaunt  I  Semaphore. Count. Type 

la  Semephore.Ceunt.Type'Lest; 

begin 

leap 

begin 

select 

ehen  Count  >  9  a) 
accept  P  de 

Count  la  Count  -  I; 
end  P; 
or 

occogt  V  4* 
begin 

Count  In  Count  •  1; 
eacegtlon 

ehen  Constraint  Error  a>  ... 
roloe  Semaphore  Error; 

end; 

end  V; 
or 


terminate; 
end  oelect; 
eacegtlon 

when  Semaphore.Error  n> 
null; 

end; 

end  loop; 

end  General  Semaphore.Type; 
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•rHWurt  f  (Sm«  i  In  C*n«nl  Swtfliir*  Tj>»)  l» 

••ft  ft 

Smm.F; 

•*4  P| 

jmWnw  V  (Sm  I  In  C«n>ril  Sm^htr>  T;*«)  I* 

J*«.V| 

•«4  V| 

kftf  1ft 

If  ■  Ml  In  Sm^ktr*  Ctunl  Tjr>«  Ikw 

r»li«  InolU  S*Mfh*r*! 

•«4  lf| 

Afa  Smfliira  F>cWf«  T»a*Ul«| 

The  most  important  aspect  of  thin 
refinement  in  the  elimination  of  the  task 
implementing  the  binary  semaphore  used  to 
serialize  access  to  the  semaphore  count. 
The  synchronization  guarantee  of  the 

rendezvous  affords  a  straightforward 

alternative  for  protecting  the  logical 
consistency  of  tho  nemaphoro  count. 
Consequently,  performance  efficiency  with 
respect  to  execution  and  storage  may  be 
improved.  Furthermore,  the  refinement 
appears  to  simplify  reasoning  about 
execution  behavior  particularly  with 

respect  to  blocking  conditions. 
Unfortunately,  by  using  the  rendexvous  to 
serialise  access  to  the  semaptiore  count, 
the  ability  to  limit  the  numbor  of  clients 
waiting  for  the  semaphore  lias  been 
relinquished.  As  a  result,  tho  procedure 
bodies  of  tho  semaphore  operations  are 
trivial,  allowing  them  to  be  inlined.  The 
triviality  was  achieved  by  promoting  tho 
exception  handling  for  detecting  semaphore 
misuse  to  a  single  accept  body  within  the 
server  task  and  allowing  an  exception  to 
propagate  to  tho  client  part.  It  should  bo 
appreciated  that  detecting  semaphore 
misuse  is  only  illustrative  and  is  not 
included  in  the  original  paradigm.  (One  of 
the  dangers  of  this  paradigm  is  its  lack 
of  protection  against  misuse  in  a  hostile 
environment,  e.g.,  arbitrary  V  opera¬ 
tions.) 

If  the  accepted  notation  for  sema¬ 
phores  is  unnecessary,  the  syntactic 
camouflage  of  the  procedural  interface  can 
be  eliminated  allowing  the  task  entries  to 
be  referenced  more  efficiently.  No 
practical  loss  in  reusability  results 
since  a  procedural  interface  may  still  bo 
obtained  by  renames  statements  for  each 
semaphore. 

Programming  for  Real-Time. 

Adapting  a  reusable  part  for  real-time 
applications  presents  a  challenge.  The 
paucity  of  formal  techniques  available  to 
specify  tho  intricacies  of  time-critical 
execution  precludes  the  confident  and 
rigorous  application  of  a  practical 


discipline.  Consequently,  an  Informal 
approach  that  introduces  a  greater  degree 
of  predictability  into  the  timing  behavior 
of  an  executing  reusable  part  must  be 
developed. 

Intuitive  in  tho  approach,  is 
minimizing  the  interaction  of  tho  temporal 
semantics  that  nay  influence  execution 
behavior.  Simplifying  those  interactions 
by  carofully  restricting  concurrency  may 
often  bo  sufficient  to  formulate  logical 
assertions  that  predict.  execution 
behavior.  This  requires  that  the  critical 
timing  dependencies  for  a  part  be 
accurately  interpreted  in  terms  of  a 
part's  execution  behavior.  For  example,  a 
general  semaphore  should  block  tbe 
execution  of  a  client  part  only  if  the 
semaphore  cannot  bo  reserved.  If  it  is  not 
possible  to  guarantee  this,  then  the 
potential  delay  from  any  additional  kind 
of  blocking  must,  be  predictable  for  the 
part  to  be  reused. 

The  eventual  acceptance  of  a  reusable 
part,  such  an  tho  abovo  genoric  package, 
for  hard  roal-timo  applications  will 
frequently  depend  upon  its  effect  on  the 
application's  execution  scheduling 
requirements.  Normally  these  requirements 
mandate  that  tho  most  urgent  processing 
within  the  application  be  completed  on 
time  with  a  minimum  of  delay;  namely,  that 
execution  is  never  blocked  unless 
deliberately  self-imposed,  e.g., 
processing  has  boen  completed  and  must 
await  some  event.  Urgency  necessarily 
introduces  tho  notion  of  priority. 
Priority  in  Ada  is  conveyed  through  the 
use  of  a  pragma  and  is  discerned  as  a 
potential  impediment  to  part  reuse. 
Consequently,  only  through  disciplined 
programming  derived  from  proven  scheduling 
theory  can  tho  use  of  priority  bo 
justified. 

Because  formal  scheduling  thoory  for 
applications  distributed  among 
multicomputers  remains  an  area  of  ongoing 
research,  scheduling  is  commonly 
restricted  to  applications  that  oxecute  on 
a  single  computer.  Thcrcforo,  it  is  in  tho 
context  of  a  single  computer  that  a  part's 
effect  on  scheduling  is  reviewed  witli 
respect  to  tho  programming  discipline. 
This  is  not  necassarily  invalidated  when 
tho  context  is  extended  to  include 
multicomputers . 

Priority  Inversion.  A  deleterious 
effect  of the  Ada  tasking  model  on 
predictable  scheduling  execution  behavior 
is  tho  potential  for  priority  inversion^. 
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Priority  inversion  refers  to  the  condition 
where  a  lower  priority  task  in  executing 
and  is  preventing  (blocking)  the  execution 
of  a  higher  priority  tank.  Each  time  a 
higher  priority  tank  calls  an  entry  of  a 
tank  that  may  have  been  called  by  a  lower 
priority  tank)  the  opportunity  for 
priority  invention  exist*.  Consequently,  a 
reusable  part  using  the  tasking  model  must 
avoid  precipitating  priority  inversion  in 
an  application.  In  particular  rendezvous 
engagements  require  careful  analysis  to 
ensure  that  the  f lrst-ln-f irst-out 
protocol  queuing  of  entries  can  be 
neutralised.  While  paradigms  using  entry 
families  can  circumvent  this  protocol,  the 
attendant  increase  in  execution  overhead 
may  limit  their  reuse  in  real-time 
applications^.  In  addition,  the  inability 
for  a  part  to  change  the  priority  assigned 
to  a  task  prevents  expediting  the 
execution  of  blocking  tasks. 

Reexamining  both  versions  of  the 
general  semaphore  shows  that  there  are  no 
safeguards  against  the  occurrence  of 
priority  inversion  when  reused  by  clients 
of  different  priorities.  This  is 
exacerbated  by  the  fact  that  when  a  lower 
priority  client  is  blocking  a  higher 
priority  client,  the  code  protected  by  the 
semaphore  is  executing  at  the  lower 
priority,  thereby  reducing  any  beneficial 
effect  from  assigning  the  semaphore  tasks 
a  high  priority.  Furthermore,  without 
analysing  the  client  tasks,  the  blocking 
time  is  unpredictable. 

Regulating  Task  Interaction.  An 
approach  to  minimising  priority  inversion, 
consistent  with  Wirth's  discipline, 
strictly  regulates  the  interactions 
between  client  and  ‘server  tasks.  Wirth's 
discipline  focused  upon  a  specific  variety 
of  sorver  task,  vis.,  device  drivers, 
based  upon  simple  utilisation  analysis. 
More  recent  researchl'1  provides  evidence 
that  when  these  interactions  rigorously 
conform  to  analytic  scheduling  algorithms 
the  blocking  of  high  priority  tasks  for  a 
simple  clans  of  client/server  tasks  can  bo 
successfully  minimised  within  predictable 
bounds.  The  algorithms  require  that  tho 
overall  timing  constraints  of  an 
application  are  subject  to  the  rate 
monotonic  scheduling  theorems,  i.o.,  tasks 
with  the  shortest  execution  periods  are 
given  highest  priority. 

One  result  of  this  research,  tho 
priority  ceiling  protocoil5,  is 
particularly  relevant  to  disciplined 
programming.  Tho  protocol  provides  tho 
necessary  understanding  for  continuing  to 


explore  regulatory  use  of  tho  task  model 
coupled  with  explicitly  defined  runtime 
system  implementation  dependencies  as  a 
practical  means  for  programming  reusable 
parts  for  hard  real-time  applications. 
Therefore,  it  is  discussed  as  a 
significant  contribution  toward 

disciplined  programming  of  Ada  tasks  in 
the  context  of  the  previous  semaphore 
examples.  The  discussion  is  incomplete  and 
should  not  bo  interpreted  as  an 
authoritative  treatment  of  the  protocol. 
It  Is  provided  to  Illustrate  that  only 
through  formal  reasoning  about  critical 
timing  dependencies  can  roliable 
abstractions  and  paradigms  be  devised  for 
effective  reuse. 

Priority  Ceiling  Protocol.  The 
priority "ceiling  protocol  assumes- the  use 
of  binary  semaphores  to  synchronize  access 
to  shared  resources  or  critical  regions  of 
code.  It  minimises  the  time  a  higher 
priority  task  is  blocked  from  reserving 
semaphore  by  lower  priority  tasks.  This 
time  is  bounded  by  the  maximum  tine  a 
lower  priority  te.sk  may  reserve  a 
semaphore.  In  addition,  it  guarantees 
avoidance  of  nontrivial  forms  of  deadlock 
in  the  presence  of  multiple  semaphores. 

The  implementation  of  this  protocol 
requires  two  important  conditions  to  bo 
satisfied.  Tho  first  condition  is  that 
whon  a  task  blocks  the  execution  of  higher 
priority  tasks  from  reserving  a  semaphore, 
this  task  should  execute  at  the  highest 
priority  of  all  tasks  it  currently  blocks. 
The  blocking  task  in  said  to  inhorit  tho 
priority  of  the  highest  blocked  task.  The 
second  condition  is  that  a  task  nay 
reserve  a  semaphore  only  if  it  is 
executing  at  a  higher  priority  than  tho 
highest  priority,  i.o.,  tho  coiling 
priority,  that  may  bo  inherited  by  tho 
tasks  it  preempts.  The  two  conditions  arc 
sufficient  to  achieve  a  prioritized 
ordering  of  tasks  that  minimizes  tho  time 
a  high  priority  task  is  blocked  when 
attempting  to  reserve  a  semaphore. 

lu  is  clear  from  the  Ada  task  model 
that  those  two  conditions  would  not  be 
achievable  by  the  implementation  of  the 
binary  semaphore  presented  earlier.  Tho 
priority  inheritance  of  the  rendezvous  is 
limited  to  that  of  tho  client,  and  tha 
execution  priority  of  tho  code  protected 
by  the  semaphore  is  static  (unless  it  is 
in  the  body  of  an  accept  statement) . 
Consequently,  different  task  idioms,  that 
do  not  procludo  meeting  the  two 
conditions,  must  be  used  for  cliont/servor 
interactions .  These  task  idioms  must 
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Adhere  to  specific  rules  that  reduce  the 
nondeterminism  of  task  execution.  In  addi¬ 
tion,  these  idioms  may  assume  an  explicit 
dependency  upon  a  "friendly'1 ,  hut  valid, 
implementation  of  the  Ada  runtime  system 
with  respect  to  the  execution  freedom  that 
may  govern  tasks  having  no  specified  prio¬ 
rity. 

The  rules  are  briefly  stated  in  terms 
of  client  and  server  tasks.  A  server  is, 
in  eirsonce,  a  semaphore  wlione  entries 
control  access  to  critical  regions,  and  a 
client  is  simply  a  non-server  task  that 
calls  at  least  one  server  task. 

1.  Each  non-server  task  must  bo 
assigned  a  priority  consistent 
with  rate  monotonic  theory. 

2.  All  server  tasks  must  be  assigned 
either  no  priority  or  a  priority 
higher  than  the  highest  priority 
non-server  task. 

3.  Each  server  task  must  comprise  a 
single  continuous  loop  that  en¬ 
closes  an  unguarded  select  state¬ 
ment. 

4.  The  select  statement  must  enclose 
only  one  or  more  accept  state¬ 
ments  and  a  terminate  alterna¬ 
tive. 

5.  Nested  accept  statements  must  not 
be  used. 

C.  Conditional  und  timed  entry  calls 
must  not  be  used. 

The  application  of  these  rules  result 
in  restricting  an  application  to  the  fol¬ 
lowing  task  idioms  if  priority  inversion 
is  to  be  controlled: 

Urt  lyp-  S«r««r  TmV.Tjm  Is 
•xtry  Crltle»l_!Uglon_J  (...)l 

•xlrjr  Critical  R«gl»n_n  (...)j 

t-»»K  k*<y  Sar-var_Taai(_Tjrpa  Is 

fcssln 
'••S 
•a I act 

accagt  Crltlcal_Sagls>n_l  (...) 

CrltlcalJUglon.i j  ... 

•r 

•ccogt  Crltlcal.RagUn.n  (...)  4o 

o«4  Crltlcal.Rogl 
tr 

UrolnaU; 
a«4  nlKi; 
an4  Ittf) 

an4  Sarvar^Taak^Tyoa; 

t»»k  i ypn  NgnSarvar„Ta*k  Typa  U 

pr ifM  rmonxiY 

•fhi  NonSarvar_Ta*k_Typa; 

iaak  NonSarvar  Task  Typa  la 

kagtn 

...  —|  Non-tarvar  It  ctlant  tttk. 

Sarvar.  Ta*k_I,CrlUcal_Raglon_1  (...);  ... 
Non$arvar_Taak_Typaj 


Tho  use  of  these  idioms  in  themselves 
do  not  guarantee  that  tho  above  conditions 
are  satisfied;  they  merely  control  task 
interaction  so  that  blocking  of  non-server 
tasks  becomes  predictable  when  the 
conditions  are  satisfied.  The  efficacy  of 
the  idioms  depends  upon  the  Ada  runtime 
system  ensuring  that  the  conditions  are 
satisfied.  The  first  condition  ia 
accomplished  by  requiring  that  before  a 
client  task-  is  placed  on  an  entry  queue 
for  a  sorver  task,  it  must  be  executing  at 
a  priority  higher  than  thft  ceiling 
priority  of  any  server  executing  directly 
or  Indirectly  for  another  client.  The 
requirement  results  in  queuing  of  only  one 
client  for  a  server,  thereby  eliminating 
the  effect  of  f irst-in-f irst-out  queues  in 
favor  of  a  single  prioritized  queue  of 
blocked  tasks.  The  second  condition  is 
accomplished  by  allowing  server  tasks  to 
be  rescheduled  as  required  by  the  set  of 
tasks  that  are  currently  blocked.  The 
rescheduling  is  legitimate  only  when  ‘no 
explicit  priority  is  assigned  to  server 
tasks  (rule  2).  In  this  instance,  the  Ada 
standard  does  not  prohibit  the  runtime 
system  from  scheduling  a  server  task  to 
effect  priority  inheritance. 

Applying  Ceiling  Rules.  Applying  the  rules 
of  the  protocol  to  the  binary  semaphore 
example,  a  reusable  package  is  constructed 
as  follows: 

panarlc 

vltti  prvcWur*  Critic*!  Raglan j 
packapa  8ln*ry.  5a<Mphara  r*ck*g«  T«*plat«  la 
ljrp«  Unary  Saaaphar#  typa  la  MaM  prlvatnj 
pracadara  P_ an4_V  (S*m  i  In  Unary, Sawaphara , Typa) ; 
prlviia 

taak  typa  llnary_Sa*aphara. Typa  la 
antry  P^an4_V; 
an4  Binary  Sa«aphora.  Typaj 
•nil  Binary, Sa*aphara  Package  T^liU; 
packapa  ka4y  Blnary^Samaphpra  P*ckaga.Ta«pl»ta  la 
iaak  ka4y  Binary. Sa*aphora_Typa  !• 
kagtn 


accapi  P„an4.V  4a 
Critical. Raglon; 
an4  P_an4_Vj 

ar 

taralnata; 
a«4  aalactj 
an4  laapj 

an4  BlnarywSaa>aphera  Typa; 

araea4ura  P_*nd,V  (Sam#  l  In  Blnary_Saaiaphora^Typa)  la 
kagln 

Sama.P  *n4_V| 
an4  R_an4_V; 

an4  Bln*ry_$aaaphora_p9ck*ga_Ta«plataj 

The  functionality  of  tho 

implementation  is  similar  to  tho  earlier 
version;  however,  the  two  traditional 
semaphore  operations  have  been  collapsed 
into  a  single  operation  that  is  explicitly 
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associated  with  the  resourco  to  ho 
protected,  i,e,,  the  critical  region. 
Consequently,  programming  of  critical 
regions  would  differ.  For  example,  the 
following  programming  treheae  required  by 
the  original  version; 


U»k  Mf  TmV.I  l> 
Vafin 

r  (Sm»)i 
Critical 
V  ($«»•)  i 
Tath.li 


laak  Mr  Ta«k  }  la 
kw*l« 
f  (S**«)| 

Critical  Raglfn; 
V  (Sar^)| 

•na  T> 1 


would  be  changed  to: 


taak  Mf  Taak  1  la 

**?'•((<  V  (!a»a)i 
•*4  Taak  lj 


laak  N4/  Taak  7  la 

V  (S~*)i 
an<  Taak  3) 


This  reduces  the  freedom  with  which 
the  semaphore  can  be  used,  vis.,  the 
clients  cannot  use  the  semaphore  to 
protect  arbitrary  critical  regions.  It  is 
apparent  that  allowing  such  freedom  is  not 
conducive  to  analyzing  the  predictability 
of  task  execution  and,  therefore, 
qualifias  as  a  potential  rule  that  would 
ho  included  in  a  programming  discipline. 


The  disciplined  approach  discussed  in 
the  preceding  section  demonstrates  some 
difficulties  of  developing  reusable  parts 
for  real-time  applications.  Adapting  a 
reusable  part  to  satisfy  hard  timing  con¬ 
straints  may  not  be  possible.  Conversely, 
the  reuse  of  a  part  from  a  real-time  ap¬ 
plication  may  bo  of fective' only  when  reus¬ 
ed  in  applications  that  suffer  tho  same 
timing  constraints. 

Tho  specification  of  a  programming 
discipline  that  ameliorates  the  difficul¬ 
ties  is  esaontial.  Tho  evolution  of  such  a 
discipline  cannot  progress  unless  there  is 
an  underlying  basis  o  practice  and  theo¬ 
ry.  Today  no  such  basis  exists  since  real¬ 
time  nno  reusability  technology  are  di¬ 
stinct  crafts  within  tho  programming  com¬ 
munity.  To  establish  the  basis  for  a  dis¬ 
cipline,  a  gradual  and  systematic  transi¬ 
tion  of  these  technologies  into  program¬ 
ming  practices  is  necessary.  This  becomes 
practical  only  through  formal  guidelines, 
proven  paradigms,  and  uniformity  criteria 
for  Ada  runtime  systems  that  sustain  tho 
guidelines  and  paradigms. 


The  construction  of  a  reusable  package 
for  the  general  semaphore  becomes 
untractable  using  the  priority  ceiling 
server  task  idiom.  The  guard  on  tho  select 
alternative  of  the  refined  version 
contravenes  rule  3  and  must  be  removed, 
otherwise  bounds  upon  blocking  time  are  no 
longer  predictable.  Its  removal  invites 
reconsidering  the  original  version  of  tho 
general  semaphore  using  two  binary 
semaphores  to  protect  the  count  reserving 
the  critical  region.  Decause  tho  integrity 
of  the  count  is  not  guaranteed  outside  of 
the  server  task  implementing  the  binary 
semaphores,  the  call  to  tho  server  task 
implementing  tho  queuing  semaphore  must 
now  be  enclosed  in  the  accept  statements. 
The  result  of  this  rovision  precipitates 
self-imposed  deadlock  that  cannot  be 
precluded  by  the  protocol. 

Only  by  increasing  task  interaction  is 
it  possible  to  imitate  the  functionality 
of  the  general  semaphore  using  the 
prescribed  task  idioms.  This  clearly 
reaffirms  that  the  general  sem&i  ore  is  an 
abstraction  oriented  toward  time- 
independent  concurrent  execution,  whereas 
the  priority  ceiling  idiom  emphasizes 
predictable  synchronized  execution  sharing 
a  single  processing  resource. 


Guidelines. 

An  example  of  informal  guidelines  that 
are  consistent  with  an  approach  to  disci¬ 
plined  programming  has  been  promulgated  in 
an  Ada  reusability  handbook^.  These 
guidelines  include  tho  fundamentals  for 
developing  reusable  parts.  While  tho 
guidelines  do  not  address  developing  parts 
that  are  subject  to  hard  timing  con¬ 
straints,  many  contribute  to  an  awareness 
of  tho  temporal  implications  that  compro¬ 
mise  part  reuse. 

Developing  and  using  theso  guidelines 
indicates  that  it  is  unlikely  that  empiri¬ 
cal  guidolinos  can  bo  formulated  to  re¬ 
spect  hard  timing  constraints.  However, 
specified  guidelines  can  result  in  pro¬ 
gramming  parts  where  reusability  has  been 
moderated  with  regard  to  performance  effi¬ 
ciency  and  execution  criticality.  For 
exomplo,  a  guideline  restricting  a  sub¬ 
program  supplied  as  an  actual  parameter  to 
a  generic  instantiation  from  use  outside 
of  that  generic  unit  would  bo  applicable 
in  the  context  of  the  generic  binary  sema¬ 
phore  package. 

Paradigms . 

Tho  derivation  of  paradigms  that  can 
be  reused  within  real-time  applications  is 
essential  to  advancing  the  discipline. 
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Paradigm*  should  synthosixo  related  guide¬ 
line*  to  comply  with  formalized  timing 
conn train l» .  Without  the  paradigm,  the 
individual  guidelines  might  possibly  ap¬ 
pear  counter-intuitive.  The  value  o £  such 
paradigms  is  evident  from  the  discussion 
on  priority  inversion.  In  this  instance 
tho  server  task  idiom  is  the  derived  para¬ 
digm. 

The  discipline  should  include  the 
reuse  of  meta-paradigms  to  support  real¬ 
time  applications.  These  paradigms  are 
used  in  the  construction  of  paradigms  that 
comply  with  formalized  timing  constraints. 
Alternatively,  they  may  support  tho  use  of 
a  specific  guideline.  An  oxamplo  of  a 
meta-paradigm  would  be  a  generic  package 
that  ensured  a  subprogram  implementing  a 
critical  region  is  reused  only  within  a 
specific  context.  An  outline  for  a  meta- 
paradigm  to  accomplish  this  rousing  the 
binary  semaphore  package  is  as  follows: 

fackift  CrltlcH  R»glsn_l*ack>o*  I* 

i;M  Raglon.CuarJ.Tj’ga  Is  ll»lt*4  prlvtlsj 
pre<s4vr«  A.CrIUcsl  R*gl«n 

(Raglon. Guard  I  In  Raglon.Cuard  Tjga) I 

gonortc 

•III)  grocoduro  Critical  Raglon 

(Roglon.Guard  I  In  Haglon.Guard  Tgpn)  j 
pockogo  Binary.  SoMphoro.Fockoga.Toaiptoto  Is 

o»d  Blnary-.Sa»aphora_r§ckaga-.Ta»ptata[ 

Unaafa.Uaa  I  oacaptlan; 
prlvata 

functlan  Ralaa  Unaafa.  Uaa  raturn  Boelaan; 
tjpa  Raglon. Typa  Is  (Hon  Critical,  Critical); 
iyi»  Cgard  Typa 

(Cgard  t  Raglon.Typa  is  Non.Crl tlcal)  la 

racord 

caaa  Cgard  la 

sKan  Critical  a) 
null; 

whan  Hon. Critical  a) 

Unaafa  i  Boolaon  ta  Ralaa  Umafa  Uia; 

and  caaa; 
and  racard; 

typa  Raglon.  Cgard.Typa  la 
racard 

Roglon  Guard  I  Guard. Typa; 
and  racard; 

and  Critical. Roglon. Pockago; 

packags  kady  Critical  Raglon  Pockaga  la 

functlan  Ralao.Unaalo.Uaa  raturn  Baalaan  la 
Safa  I  Boolaon  is  Falsa; 

Was  In 

It  Safa  tkan 
raturn  Trua; 

alaa 

ralaa  Unaofo.Uao; 
and  It; 

and  Ralaa.Unaafa  Uaa; 
pracadura  A.CrltlcoI.Raglon 

packaga  kady  B1nary_Saaaphora.Packaga_Tsmplata  la 
task  kady  8lnary_So*aphoro_Typa  la 
kagln 
loop 
oatact 

accapt  P_or.d_V  da 
Crltlctl.Roglon 

(Roglon.Cgard  Typa* (Raglon  Cuord  a> 
Ggard_Typo' (Guard  a>  Critical))); 
and  P.and.V; 

and  Blnary.Saaaphora  Packaga; 
and  Crltlca l_Roglon_Pockogo; 


The  above  paradigm  requires  that  each 
critical  region  include  an  additional 
parameter  to  restrict  its  rouse  to  the 
binary  semaphore  package.  This  necessitat¬ 
ed  a  minor  change  to  the  binary  semaphore 
package . 

In  tho  near  term,  the  uso  of  paradigms 
may  bo  the  only  practical  means  for 
developing  partitioning  strategies  for 
real-time  applications  that  must  be 
distributed  among  multiple  computers. 
Paradigms  such  as  those  derived  from 
virtual  nodesl7  place  specific 
restrictions  upon  the  locality  of  parts, 
thereby  extending  the  programming 
discipline  into  moro  global  concoms  that 
have  been  left  unaddrossod  in  this 
approach  to  disciplined  programming. 

Uniformity. 

A  prevailing  maxim  when  programming 
Ada  reusable  parts  is  to  avoid 
dependencies  on  runtimo  system 
implementations.  For  part  reuse  in  real¬ 
time  applications  the  strict  adherence  to 
tills  maxim  must  be  relaxed  because  of 
application  timing  constraints.  Critical 
timing  constraints  can  bo  achieved  only 
when  runtime  system  implementations 
conform  to  precisely  defined  semantic 
interpretations  of  tho  Ada  standard  that 
load  to  practical  real-time  execution 
models. 

The  priority  ceiling  protocol  is  a 
convincing  example  for  programming 
reusable  parts  based  upon  a  "friendly" 
implementation  of  the  runtime  system.  The 
example  demonstrates  that  i;  parts  are  to 
bo  reused  in  a  real-time  application, 
where  priority  inversion  must  be  bounded, 
dependencies  upon  tho  runtimo  system  can 
be  used  to  program  effectively  reusable 
parts.  This  warrants  a  programming 
discipline  that,  while  legislating  against 
uncontrolled  use  of  implementation 
dependencies,  is  sufficiently  flexible  to 
promulgate  controlled  uso  of  Ada  real-time 
models.  Controlled  use  implies  that 
uniformity  criteria  be  established  for 
runtimo  systems.  The  discipline  would 
roquiro  that  tho  reusability  of  a  part  bo 
qualified  with  respect  to  the  uniformity 
criteria  satisfied  by  a  runtimo  system. 
For  example,  a  part  that  must  tolerate  a 
Storago_Error  exception  might  require  that 
the  runtime  system  guarantee  the  execution 
of  tho  exception  handlor  for  the  frame 
that  suffered  the  exception.  Consequently, 
rouse  of  the  part  would  be  qualified  by 
this  requirement. 
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A  corollary  in  that  all  reusable  parts 
constituting  an  application  must  depend 
upon  the  sane  or  compatible  uniformity 
criteria.  Thin  would  ameliorate  tha 
potential  problem  that  currently  exists 
when  parts  with  conflicting  dependencies 
are  combined.  Conflicting  dependencies 
become  detectable  since  the  discipline 
would  require  the  assertion  of  uniformity 
criteria  for  each  reusable  part. 

Loveraging  tho  Ada  runtimo  system  to 
program  reusable  parts  for  real-time 
applications  is  expected  to  incroase. 
Initiatives  such  as  the  International 
Standards  Organisation's  Uniformity 
Rapporteur  Group  are  evidence  that 
uniformity  of  runtime  systems  will  evolve 
in  tine  to  support  the  objective  of 
disciplined  programming. 


Conclusions 

Ada  promotos  many  of  the  programming 
language  practices  that  Wirth  perceived 
when  proposing  a  discipline  for  real-time 
programming.  This  paper  has  borrowed  from 
this  proposal  to  argue  tho  necessity  for 
extending  tho  discipline  to  construct 
reusable  Ada  parts  for  real-time 
applications.  In  addition,  it  has 
emphasized  that  the  desiderata  for  a 
discipline  comprise  guidelines  and 
paradigms  that  roly  on  sound  theoretical 
principles  and  improved  uniformity  of  Ada 
runtimo  systems. 

It  is  apparent  that  extending  tho 
discipline  to  increase  software  rouse 
among  real-time  applications  offers  a 
challenge  not  only  to  the  fundamental 
principles  of  tho  original  discipline  but 
to  Ada.  Tills  paper  has  provided  a 
perspective  on  tho  scope  of  tills  challenge 
by  suggesting  a  proposed  discipline. 
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Abstract 


A*  a  pa;tlclpant  in  the  Ada  Xtu.t  and  nettiea  Atstarch 
JllSIi  ixlnp  canducttd  for- th«~ Army  Tnatllula  lor  XeTeaTefi 
*n”  danageaenl,  InioruUim,  Caaavnlcettona  and  Coaputer 
Science  (AIMICS),  th«  horehouse  College  Software  Croup  has 
completed  two  tutu  A  etudy  of  th«  appropriateness  oi 
tovtiol  database  aodtli  (or  supporting  reutsblllly  toolt  in 
currant  »nd  (uiuro  Integrated  programming  environments!  (hr 
development  o(  a  conceptual  model  o(  on  estentlble 
integrated  software  development  environment  which  utilises  o 
coaaon  objsct-orlsnted  database  subsystem.  The 
Object-oriented  Dst.bssr  model  hoc  bran  Selected  ot  (hr 
preferred  aval,  Norrhoutr  Collage  L  curramly 
implementing  o  .ado  rturr  library  oyalro  using  enisling 
object-oriented  dotobotr  technology. 


motivation  (or  thio  rrotorch. 

7hl  s  oiudy  o(  dou  nodtlo,  library  strategies,  and 
engineering  tnvlrenmante  wot  principally  influenced  by  (hr 
dtolrt  to  accoMOdait  Information  pertinent  lo  ooltwar* 
patio  and  tht  prectoi  by  which  ihty  writ  developed. 

Tht  coupling  o(  library  management  with  configuration 
management  reflect.  an  aatuaption  that  tht  utility  e(  a 
large-teal*  rtutt  library  Implementation,  which  capiuttt  and 
archive.  engineering  taptritnet  at  wall  at  eoftwet* 
component.,  nutt  rtly  htavlly  upon  tht  application  oi  aound 
ptincipitt  of  configuration  management. 

Thtt  ftemewotk  ia  a  generalised  organisation  tchtno  (or 
rtutt  librarltt.  it  providtt  a  framework  (ton  which  nany 
typat  of  llbrarlta  >  Urge  or  taall,  public  or  private  -  nay 
bo  dttcribtd. 


1.1  Library  Attributta 

Tht  conttnta  and  utt  o(  ont  library  nay  vary  greedy  with 
that  o(  another.  On#  library  might  ba  a  large,  national 
rapoaltoty  o(  part  dtacriptiont,  (or  general,  public  accata. 
Another  might  ba  a  Urge,  yat  local  coapany  rtpotltory 
constating  of  both  partt  and  thtlr  dcteriptlont  (or  utt  in  a 
proprietary  project.  while  tht  latter  library  it  private, 
any  number  of  parti  nay  have  bean  laportad  (ton  other 
llbrariaa.  Thut,  a  high  degree  of  coaaonality  among 
librarltt  ahould  ba  sought. 

At  tttn  above,  reuse  libraries  aay  be  claiaidad  in  taraa  of 
a  nuabtr  of  attribute!.  Stvtrtl  aejor  attribute!  ere 
onuaertted  below. 


1  lUKAhy  MAHAGMINT  1SSUSS 

1.1  tntrcductlon 


The  Idee  of  building  eoftwtre  tytttat  frsa  ealitlni 

recooMtad  hi**  hi Iy  ol?  '  P*th,P*  0lJ  enough  to  have  bee! 
r«cognl!tn  by  ft*bb*£«.  At  t  result  of  recent  research. 

iII?iV5r\hUl?  e0?e5pt  oi  {*u*»blHty  hot  evolved  in  .cope  tr 

llfl  IvcU  KxW«?I  ?I  JId  *  *»“«««  divelSoItM 

if  ,l#  *•*}  •*  ***•  software  co»pon«nt«  Iheatelvts, 

e“r*ni  opinion  eapha.ire.  thtt  reu.e  archival 
should  capture  procett*  along  with  "product*. 

!?!!*  that  the  potentltl  dividends 

froa  the  Investment  in  developaent  end  know-how  is  nueh 
9fetfer  than  that  froa  the  coftvare  coaponents*  This  in 

o»sctllal°UI  ‘!ChMe*1  ^iipl.^^tioS 

of  n  practictl  rtutt  rspotitory,  utt  the  compelling 


1.2.1  Silt  - 

Tht  Site  attribute  represents  (be  nuabar  of  parts  contained 
in  a  library.  The  purpose  of  this  attribute  it  to  provide 
the  user  with  Information  which  would  help  deteraine  a 
search  strategy  for  using  tht  library.  This  attribute  bears 
directly  upon  the  aanner  end  speed  with  which  a  user  say 
navigate  through  the  library,  f ot  txaaple,  a  user  eight  not 
opt  lor  a  "shotgun*  search  atattgy  when  accessing  *  library 
which  contains  a  very  large  nuabar  of  pertt. 


1.2.2  Parts  Domain  - 

The  pert  domain  attribute  la  a  list  of  the  classes  of 
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rlrit*  J.  A  Mbt*«y 


1.  Ubt»:y  Suuciutg. 


A  MULTM.EVCL,  SINGLE  DOMAIN  UMAR  Y 
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otfenliailen  irlfure  (I 


I 

uvct. 


f3> 

o 


APART 

*  AVAILAILC  INFORMATION 

•  UNAVAItAtlC  INFORMATION 


rlyut •  S.  mi  components. 


1.3.4  Scope  - 

The  Scope  attribute  describes  ih«  rente  of  users  which  can 
ok  th«  lh«  library  to  provide  services.  Scope  supports  the 
notion  of  libraries  which  *t«  flobally  public  or  private,  as 
w«ll  oi  chit  of  llbnrlti  which  it*  public  or  pclvit*  within 
«  cirtiin  l«v«l  of  i  network  domain.  Tor  lnitinct.  in 
organisation  uy  poim  ltbrirlil  which  It  dual  public  only 
within  th*  orfinltitlcn.  It  aty  alio  dicliri  othir 
ltbrirlil  to  b«  prlvitt  to  cirtiin  groups  within  tht 


WIDE  AREA  RESEARCH  NCTfcORR 

- j - l - 

AJhO  PRIVATE  ORGANIZATION 


I  I 


n  n 

^"*1  •>  REUSE  URRARY 


1.)  Library  Parti 

He  dattna  a  part  to  be  lha  fundaaantal.  cataloeued  unit  of  a 
library.  A  part  contain!  aoaa  or  all  of  tha  producti 
created  durlny  the  aoftwarc  development  life  cycle  phases  of 
a  software  component.  In  addition,  a  part  nay  have 
attributes  stored  with  It  alonf  with  Its  relationships  to 
other  parts  |3)|. 

The  Ada  Reusability  Guidebook  su)9ests  a  comprehensive  list 


458  7th  Annual  National  Conference  on  Ada  Technology  1989 


#<  Inloruilon  tnd  aiteeialtd  data  *l«*«ntt  that 

b*  ttoud  villi  *v*ry  ce*p*n*ni  upon  inclutlon  In  * 
llbtaiy  till.  A  partial  liatlny  it  at  lollowti 

SiSMSiX 


C*v«lO(.«r 

tnvltcna«nt  itpoitd,  «.y.  I'etptltr,  toolt.  ritlfMoli 
Mmttllliy  iwulti 


rAW  assent r;t»t 

Till* 

TYP*  o(  fart  iced*.  .Jealyn.  «tc.l 
Typ*  o!  function 
rutpot*  o(  runctlon 
Inutlac*  p*yulr»a«nit 

fAbT  COrfSTimxTS 

Mikih 

b»yulr*a*nt  Sp«el  (Ira  wan 
Functional  Spicldcatlon 
0«ii(n 

Alyortih*  or  function 
sourer  Cod* 
obj«et  Cod* 
tnl  specification 
Tin  cod* 

Tilt  Dot*/  Hi  lulu 


Oth*r  ceityorltt  t(  information  include  oitclalMii. 
Sodwat*  tuppari,  nlirilUMMI  Iniitucilene.  tod  R«dla. 


1.1.1  l»ri  tuiMlbllliy  - 

Inliully,  It  It  llltly  that  only  4  minima*  tot  o( 
ln(ot*ation  •  caitcoilot  ctn  h«  ayt«*d  upon.  Mt««v«r,  *  pan 
It  t  'anapahot*  ot  «  continuity  eodwaio  d«»«lop»*ni  ptoettt 
tnd  lu  product*  tl  to**  tdi*t«  In  iht  111*  eyel*  o(  t 
todwti*  coaponm.  Tti*  d»u  U**t  within  *  p»ri  wilt  haw* 
10  b«  updtud  wh*n  *odldcatlont  to  *  to(lw*i<  coaponm. 
tueh  *t  buy  (U*t.  *i*  mi*,  ruiut*  todwti*  d*v«itp«**ni 
tool*  tnd  ptot«lt*t  »*y  ntctttlltl*  lb*  addition  *(  ntw 
Infoinatlen  cattyotlat  to  tb*  library  icbtna,  at  w*ll  at 
•odldcatlont  to  tb*  tiUtlny  tcbiu.  Tb*  llbtaiy 
btcbtuctur*  tb«r*(ot*.  ptovld**  (or  tb*  addition  and 
nodldcttton  o(  tnfomatlon  cauyorltt  and  thtlr  ataoclaltd 
data  «>*»«ntt. 


«M  K I  ITCHY 

b«aton  (or  fart  0«v*lopa«nt 
Oat;*  o(  Co*pl«tlon 
o«tcr Iptlont  o(  application!  Ut«d 
rreyumy  o(  Ut« 

o*tcrlptlon  o(  Ctvdepxnl  tttndardt 
V«ttlon  Ku*b«r 

SUtnlTTtn  DATA 

Kta* 

Addr«at/  Network  Addralt 
fhon* 

Contact 

»AbT  ATTbltUTtS 

b*yvordt(  to  t«arch  enl 
0«y*lop**nl  tanyuay* 

Mott  environment  l  CoapuKt  tnd  Optratlny  Syn**) 
Ttry*t  Snvlronam  (Computer  and  Op*tttlny  Systaal 


bciTM  croons 

Cov«rn*«nt 


1.1.1  bulb  ln(or*atlon  - 

bull  ln(or*atlon  tuch  at  tourc*  cod*  and  dacu**nttllon  nay 
b«  i«(*r*nc*d  by  pointer*  tor  l(  ttoray*  potaltt,  bull 
Information  »ay  b*  ttorad  In  a  llbtaiy  alony  with  tb*  otb«r 
tnloraaiton  contain  In  a  ptrt. 

It  hat  b**n  r«coynlt*d  that  hlyher  d*yt«*t  o(  etui*  o( 
ln(or*atlon  contaln«d  In  nonolllhlc  lt«*t.  tuch  at 
ip*el(lcatlon  documentation,  could  b<  pto*ot*d  by  tipttiilny 
th*  tn(or*atlon  In  tnall,  tautabl*  ytoupt.  rot  Inttanc*. 
tp«cl(lcatlon  document*  could  b«  manipulated  at  t*tt  o( 
taalltr  tpacKIcatlont  |),S,I). 

It  It  htybly  dttlrabl*.  th«i*(or«,  (or  th*  library 
•anaytatni  tyttt*  to  provld*  torvlctt  (or  maalpulatlny  bull 
ln(or*atlon  lltot  In  th*  appropriate  loylcal  part*.  Tbit 
could  b*  acco*pllih«d  by  Itorlny  loylcal  and  btbavlottl 
qualltltt.  tuch  at  a  ptttlny  mechanllm  and  th*  approprlat* 
tyntat  ,  o(  a  bulb  Information  It<«  In  lb*  library.  Tbit 
hat  b«*n  d«»onttrat«d  utlny  obl*cl-or!«nt*d  dtttbat*  tyntat 
19*121. 


1  THE  must  LIbbAbY  SYSTCK 

In  thll  ttcllcn  yc  -Jlv?  an  bv*ivi*w  u(  uui  evaiyn. 
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Out  <!»•  l In  hat  three  levelti  »n  abject  -mlenied  datebiie 
which  uim|ii  *  ttutv  libraries,  a-*  «ivU^»Hen  In'ellaee  ta 
the  object-oriented  dalifeite.  »n-l  *-  integrated  Mttlwtie 
engineering  environment.  Al  the  lime  this  wilting.  *ur 
wfliv  It  being  CMtftlMtdl  tut  Ihc  rSttahate  level  at  the 
syne*.  x 


:.l  The  Integrated  leliwttc  Engineering  tnviiciaenl  level 

Our  Integrated  totiwtre  engineering  environment  will  be 
constructed  by  coupling  several  vnitung  malt  In  aur 
research  envltonaenl.  Me  will  be  vied  la  >«iu|e  the 
aubprecciscs  needed  ta  execute  the  mult  in  the  > oviionaent. 
In  addlllf-n,  the  uter  Interlace  win  be  tenutucied  in  Adi. 

The  natlvttlant  behind  the  ute  at  integrated  rof.rre 
engineering  envlrocaentt  era  well  known,  An  envltan«ent 
canilnlnt  al  a  art  at  tightly  coupled  e»-**lt  which  ptetenu 
a  cantlttent  uter  Interlace  can  ttiaulate  tytlea  cancepllan 
at  a  high-level  at  abttrectlan  and  cars  be  configured  la 
support  a  particular  design  methodology  le.g. 
object-oriented,  procedural,  ete.t  U.7I.  The  mala 
caapetate  to  tuppnn  the  develwpaenr  elicit.  A  cantlttent 
uter  Interlace  eltalnafes  the  heed  Ini  the  developer  la 
petleta  aental  Central  iwiichea.  which  can  reduce 
productivity  U.lll. 

In  addition  to  having  a  Canaan  uter  Interlace  raang  taalt,  t 
tightly  coupled  environment  It  one  in  which  the  loolt  thtle 
Interaedtate  repretenittiant  al  taltwtre  being  deeelaped  In 
the  envlranaent.  One  approach  that  hat  bean  taken  It  ta 
have  the  taalt  there  a  coaaen  dttabate  which  aanaget  all  the 
lorai  and  vertteni  a  aoltwarc  tytlea  aay  have  during  lit 
1 1 (e  cycle  IS.t.fl.  The  detlrable  eharacterlttlci  ol  an 
Integrated  toltware  engineering  envlranaent  atei 

1.  that  It  be  ealenttble,  that  u.  it  tuppattt  the 
convenient  addition  al  taalt  to  the  envlranaenli 

1.  that  It  aupporti  Interoperability,  that  It,  all  taolt 
that a  the  taae  underlying  deiabeie  repretentatlont,  and 
they  properly  Interpret  thete  representations. 


NETWORK  TOfOlOCY 


flgtlfe  I.  network  topology 


catentiblllty  can  be  achieved  In  a  large  part  through  the 
ute  Ol  t  coaaon  dttabate  |}|.  Interoperability  can  be 
achieved  through  the  teleclion  ol  an  underlying  dttabate 
■odel  which  hit  lleaible  and  robuat  modeling  capabllltlea 
(figure  71  IS.g.gJ. 


AN  INTEGRATED  SOFTWARE  CNSINtt  RING  ENVIRONMENT 
/ - — — — - - — • - - 
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figure  7.  An  Integrated  soltvan  engineering  wnvlronment. 


J.2  The  oatabate  Application  Interlaco  Leval 

The  database  application  Interlace  will  provide  a  coaaon 
protocol  with  which  the  tools  In  the  Integrated  toltware 
environment  will  ute  to  communicate  ulth  the  database.  The 
Interlace  ulll  alto  provide  a  bridge  between  the  procedural 
features  In  Ada  and  the  protocols  used  to  cosaunicate  with 
objects  In  the  database  {figure  t,  SI. 


hORUrAlIJn/ 

NAiefiutrC 
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WUII  UWKInUl 


riyut*  t.  library  nanaymnl  atthiuclur*. 


2.)  Th*  obj*ei  Calabar*  t«vel 

Th*  diubaii  wilt  aupport  an  *n<nalhl*  tbjact  teh*na  (or 
maintaining  ItbrarUa  ot  ttuaabl*  aoftvat*  component*.  noil, 
ot  th*  «ntlil«*  In  th*  databat*  will  b«  ceapl**  p«itlat*ni 
ebjtcu.  That*  object*  will  b«  o(  »«v*r*l  dimii  library 
object*.  pm  object*.  iivmi  pm  conitliutnt  object 
cIiimi,  and  iiviul  olh«r  rp*clal  objtet  claim. 

taeh  *•  -  "I  ho  both  altuciural  amt  behavioral  proptrtla*. 
Tha  tvi.ctut*  ot  an  object  nay  bt  dticrlbed  In  t*m»  ot  th* 
nwantlty  and  claries  ot  esntlilurni  objects  It  contalnt. 
Th*  behavioral  properties  et  an  object  at*  d*tc«lb*d  In 
mot  et  th<  method*  Iproctduteal  which  nay  b«  uttd  to 
ceasuntcai*  with  th*  object  to  obtain  letvlee*.  tach  clatt 
ot  object*  will  havt  aethodt  d«fin«d  to  provide  urelul 
t«(vic*t  to  th*  application  interface  l«v«l,  tuch  at 
creating.  displaying  and  nodilymt  eb]«cu< 

thtt  Syrian  It  belny  l*pt*n*ni*d  utlny  th<  CenSien* 
ebjeet-orlanted  dattbtct  tyttt*  1101. 


2.1.1  library  Object*  - 

hi  th«  hlyheit  1* v* 1  ot  th*  databat*  tch*»t  at*  llbtaty 
object*.  rather  than  treating  th*  databat*  «*tv*r  Unit  at 
a  library,  th*  tchtna  d*lln*t  llbtaty  object*  which  at* 
coapltt  objects  containing  pm  object*.  by  detlnin*  a 
llbtaty  at  an  obJ«ci.  a  slnyle  databat*  t*tv«t  can  ioylceily 
naney*  not*  than  on*  ytouplny  ot  llbtaty  ot  pattt.  rot 
■aatpl*.  an  orysnliailon  nay  with  to  oainialn  ttpattt* 
libraries  tot  «ach  ot  lit  d*pattn*ntt  In  a  tlnyl*  databat* 
t*tv«r  irtyut*  10,  III. 


**)Mt  »•(•***• 


rlyut*  10.  Objtet  bat*  structure. 


_ tiwagoalitli 

i  op  -  g 

M7 

r*#i  Njim 


figurs  11.  Library  objtet  ttru-tut*. 


2.J.2  fsrt  Objects  And  fsrt  Constituent  objects  - 

A  p*ft  object  U  *n  extensible  cltss  of  objects  vhlrh  suy 
contsln  sqm  or  *11  of  iht  pioducts  9enec*ted  during  the 
lifecycle  ot  *  toftvs'e  component.  for  extsple,  »  p*ct 
object  «*y  conuln  soae  Ok  all  of  the  following  infocaationi 
part  classifications,  docuaentation,  source  code,  test 
results,  and  part  history,  each  of  these  different  types  of 
infor»»tlan  are  represented  by  a  cooretponding  class  of 
objects  whose  instances  are  constituents  of  part  objects 
(figure  I2i. 


r*n  cijici 


fMt  (iMtiiiid  eijtcli 


riyure  12.  Pact  object  structure. 
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problem  potct  a  dilemma.  will#  practical  Implementations 
«H  be  touphl  new,  a  parallel  effort  nil  be  mounted  10 
dayalep  notability  methodoloplti  and  toota  that  vUl  be 
sufficiently  fleilble  and  robutt  10  allow  the  Incorporation 
of  future  propraamlnp  trchnaloplet. 

Tba  object-oriented  data  model  appaata  to  have  evervhflainp 
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SUMMARY 

Although  some  aspects  of  the  software  development 
life  cycle  have  been  adapted  to  deal  with  reuse,  oth¬ 
ers  have  been  ignored.  In  particular,  the  verification 
and  validation  (V&V)  process  has  not  been  adapted 
to  deal  with  reusable  components.  During  the  past 
year  the  authors  ha>  *  investigated  the  verification 
and  validation  of  rcusaw>  software  components.  As 
pan  of  that  project,  a  review  of  different  software 
development  file  cycle  models  was  conducted  in 
order  to  determine  their  applicability  to  Ore  develop¬ 
ment  of  reusable  software  and  the  preferred  V&V 
techniques  associated  with  each.  Among  those  stu¬ 
died  were  the  "Waterfall,"  "2167.”  "2167A*.  the 
Software  Reusability  Guidebook,  and  the  Spiral 
Model.  In  so  doing,  each  stage  of  the  different  life 
cycles  was  studied  from  the  perspective  of  the 
relevance  of  the  prescribed  methods  to  reuse  and  to 
V&V.  This  paper  summarizes  the  results  of  that 
study  and  proposes  some  methodological  chances 

Sired  towards  making  software  development  with 
a 'produce  more  reliable  and  reusable  code. 


Mffislufiiimi 

The  ability  to  reuse  software  has  been  heralded 
as  one  of  Ada  $  biggest  benefits.  Nonetheless,  there 
have  been  few  meaningful  example-  of  software  reu¬ 
sability  within  the  Ada  community.***  Part  of  the 
blame  can  be  attributed  to  the  fact  that  Ada  is  new 
and  still  not  completely  understood,  that  Ada  com¬ 
piler  technology  has  only  been  in  place  for  a  few 
years,,  and  that  programming  environments  for  Ada 
arc  still  being  developed.  More  significant,  however, 
is  die  fact  that  the  methods  being  used  are  those 
derived  from  (raditk.iud  software  development. 
Although  some  aspects  of  the  software  development 
life  cycle  have  been  adapted  to  deal  with  reuse,  oth¬ 
ers  have  been  ignored.  In  particular,  the  concepts  of 
validation  and  verification  (V&V)  have  not  been 
adapted  to  deal  with  reusable  components. 


During  the  past  year  the  authors  have  been 
involved  m  the  development  of  software  tools  and 
methods  to  be  used  for  the  validation  and 
verification  of  reusable  software  components.'-*  As 
part  of  that  project,  a  review  of  different  software 
development  lire  cycle  models  was  conducted  in 
order  to  determine  their  effectiveness  in  die  actual 
development  of  reusable  software  and  the  preferred 
V&V  techniques  associated  with  each.  Among 
those  studied  were  the  "Waterfall,”  the  “Spiral 
model,  "2167,"  "2167a,"  the  "Domain-Oriented" 
model,  and  the  Software  Reusability  Guidebook, 
'litis  paper  summarizes  the  results  of  the  study  and 
proposes  some  methodological  changes  onented 
towards  making  software  development  with  Ada  pro¬ 
duce  more  reliable  and  reusable  code. 


'Hie  waterfall  model'*  consists  of  six  stages: 
requirements,  specifications,  detailed  design,  coding 
anti  unit  testing,  integration  and  system  testing,  and 
maintenance.  Each  stage  incorporates  V&V  activi¬ 
ties.  How  to  conduct  V&V  L  net  explicitly  stated  in 
the  methodology  and  is  thus  up  to  the  software 
developer.  'Hie  model  also  docs  not  explicitly  indi¬ 
cate  a  preferred  programming  methodology,  thus 
allowing  the  possibility  of  reusing  parts  by  basically 
designing  only  to  the  level  where  the  parts  would  fit. 

'Hie  Waterfall  Model  was  developed  before 
reuse  was  a  major  concern.  As  such,  it  makes  no 
comments  on  development  for  the  sake  of  reuse.  It 
is  important,  however,  because  it  is  the  development 
method  generally  taught,  in  computer  science  pro¬ 
grams  and  because  it  is  die  standard  against  which 
other  life  cycle  models  arc  measured. 
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B&Mal&sdsl 

The  Spiral  Model*  wax  developed  by  Barry 
Boehm  as  a  mechanism  for  reducing  the  risks 
involved  in  developing  software  un  ng  traditional 
methods  At  each  stage  of  die  process,  risk  analysis 
is  cone  J  ami  the  developer  follows  the  path 
which  minimises  risk.  'Hie  Spiral  Model  consists  of 
several  cycles,  cacti  cycle  consisting  of  four  phases. 
'Hie  first  phase  is  used  to  elaborate  the  objectives 
and  constraints  of  the  current  cycle.  Hie  second 
phase  evaluates  the  cltematives  with  respect  to  the 
objectives  and  constraints  expressed  in  the  first 
phase  of  the  cycle.  The  third  phase  consists  of  the 
development  and  testing  of  the  specific  product 
being  developed.  The  methodology  used  during  this 

phase  is  up  to  the  developers.  ’Hie  Iasi  phase  is 
uscu  to  review  die  achievements  of  the  current  cycle 
and  to  initiate  planning  of  the  following  cycles. 

'Hie  model  described  above  does  not  depend 
upon  any  particular  development  technology.  It  is 
simply  an  approach  to  managing  software  develop¬ 
ment.  One  of  the  objectives  stated  in  the  first  phase 
of  a  cycle  might  be  to  achieve  a  certain  level  of 
V&V.  die  model  itself  does  not  describe  how  that 
would  lie  done.  Determining  if  such  an  objective  is 
achievable  is  one  of  the  problems  that  the  developers 
would  face  in  the  second  stage.  The  model  as 
described  allows  for  the  incorporation  of  any  avail¬ 
able  technology.  'Ilitis,  if  certain  technologies 
became  available  for  use  within  a  project,  (i.  c.  a 
system  of  reusable  pans  with  an  integration  mechan¬ 
ism,  a  V&V  tool,  etc.),  the  model  allows  its  incor¬ 
poration. 


IMkSXP-lLfiZ 

DoD-STD-2167*  establishes  the  requirements  to 
be  applied  during  the  development  and  acquisition  of 
mission-critical  computer  system  software.  It  con¬ 
sists  of  a  specific  set  of  steps  to  be  followed  through 
the  software  life  cycle.  The  system  development 
cycle  consists  of  four  stages:  the  concept  explora¬ 
tion  stage,  the  demonstration  and  validation  stage, 
the  full-scale  development  stage  and  the  production 
and  deployment  stage.  Relevant  software  develop¬ 
ment  usually  occurs  during  the  full-scale  develop¬ 
ment  stage.  Hie  software  development  cycle  con¬ 
sists  of  six  phases:  1)  'Hie  software  requirements 
analysis  phase,  2)  the  preliminary  design  phase,  3) 
the  detailed  design  phase,  4)  the  coding  and  unit 
testing  phase,  5)  die  computer  software  component 
( CSC)  integration  and  testing  phase,  and  6)  the 
CSCI  testing  phase. 

The  software  development  life  cycle  proposed 
by  2167  includes  formal  and  informal  reviews  and 
the  development  of  formal  and  informal  test  pro¬ 
cedures  for  V&V  of  the  product.  The  specific 
design  and  testing  methodologies  used  arc  left  up  to 
the  user,  although  a  top-down  approach  Is  suggested 
for  the  design,  coding,  integration  and  testing. 


DoD-STD-2167  docs  discuss  reuse.  It 
encourages  contractors  to  "incorporate  into  the 
current  software  design  commercially  available 
software.  Government  furnished  software,  and  .reus¬ 
able  software  developed  for  oilier  applications  . 
I  lowever.  it  does  point  out  the  V&V  or  the  reusable 
parts  is  the  responsibility  of  the  contractor. 


DoD-STD-2167  A*  is  a  recent  revision  to  DoD- 
STD-2167  that  describes  the  ,  , 

uniform  set  of  requirements  for  software  develop¬ 
ment  which  are  applicable  throu&lioutthc  life  cycle, 
it  is  important  to  note  that  DOU-STD-2167A  does 
not  describe  a  preferred  life  cycle  nor  does  it  impose 
a  software  development  ncthod.  DoD-STD*2lo7A 
uses  the  same  software  life  cycle  described  by 
DoD-STD-2167  as  a  sample  to  explain  the  set  of 
rcquiremems  imposed  bv  the  standard.  DoD-SfD* 
2 167 A  differs  from  DoD-STD-2167  in  die  level  of 
details.  Whereas  DoD-STD-2167  tried  to  be  very 
specific  as  to  how  certain  activities  are  to  be  con¬ 
ducted,  DoD-STD-2167A  still  expresses  the  need  for 
such  activities  but  does  not  go  into  the  amount  or 
detail  as  to  how  they  arc  to  be  performed. 

DoD-STD-2l67A  introduces  a  few  new  terms  to 
define  old  ideas.  One  of  diem  is  Nan-ilcvefopmeniai 
Software  (NDS),  which  is  any  software  that  is  not 
developed  under  the  contract  but  is  provided  by  the 
contractor,  the  Government  or  a  third  party.  NDS 
can  be  considered  to  be  equivalent  to  reusable 
software.  DoD-STD-2167  A  encourages  the  use  of 
NDS  by  requesting  that  the  contractor  consider 
incorporating  NDS  into  die  deliverable  software  and 
document  iis  plans  for  using  NDS.  It  gives  permis¬ 
sion  to  use  NDS  without  approval  from  the  contract¬ 
ing  agency  as  long  as  the  NDS  is  fully  documented 
in  accordance  with  the  standard. 


A  final  item  of  interest  concerning  DoD -SID- 
21 67  A  is  the  continuous  encouragement  for  the  use 
of  automated  tools  to  support  the  software  develop¬ 
ment  effort.  Such  tools  range  from  software 
engineering  environments  (SIlus),  software  test 
environments  (simulation  software,  code  analyzers, 
etc),  to  simple  revision  control  systems.  Whereas  a 

treat  deal  of  detail  has  been  omited  from  DoD- 
TD-2I67A.  the  document  does  touch  on  a  few  new 
areas  and  docs  encourage  the  use  of  automated  tools 
that  will  hopefu.ly  fill  in  die. amount  of  detail  that  is 
needed  to  perform  the  activities  adequately. 


The  Domain-Oriented  Software  Life  Cvc’S 

A  literature  search  did  reveal  one  paper  describ¬ 
ing  a  software  life  cycle  model  that  specifically 
addressed  reuse.  This  was  the  Domain-Oncntcd 
Software  Life  Cycle  model  developed  by  Mark 
Simos  at  Unisys  Corporation.*  The  domain-oriented 
life  cycle,  on  uic  otiier  hand,  closely  models  the  way 
software  is  actually  developed.  It  takes  both  a  top- 
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down,  problem-driven  approach  and  a  bottom-up, 
parts-driycn  approach.  Development  iterates 
between  die  two  approaches.  Infonnation  front  pre¬ 
viously  developed,  related  applications  is  used  to 
guide  top-down  development.  Using  related  applica¬ 
tions,  or  domains"  as  die  source  of  reusable  enti¬ 
ties  makes  reuse  more  natural  and  achievable 
because  the  same  types  of  objects  are  handled  and 
the  same  types  of  problems  arc  solved.  A  particular 
domain  could  mature  to  die  point  that  developers 
have  templates  for  every  stage  of  the  life  cycle  and 
need  only  fill  in  the  details  mat  pertain  the  the  par¬ 
ticular  application  at  hand. 

”A  domain-oriented  life  cycle  formalizes  lypicu 
patterns  in  the  development  or  a  related  series  of 
applications  and  the  persistence  of  information  from 
one  application,  to  the  next.'*  It  requires  new 
methods  of  analysis  to  determine  whsi  parts  of  a 
particular  application  arc  appropriate  Tor  reuse,  and 
how  that  information  should  be  kept.  For  applica¬ 
tions  with  significant  amounts  of  redundant  code, 
bimos  proposes  the  use  of  Application-Specific 
Languages  (ASLs).  An  ASL.  is  a  non-procedural 
specification  language  that  lias  been  developed 
specifically  for  a  class  of  applications.  A  translator 
could  be  used  to  translate  a  specification  in  an  ASL 
into  the  code  of  a  high  level  language.  Applications 
that  can  be  used  in  a  variety  of  situations  {e.g.  a  sta¬ 
tistical  package)  could  be  .developed  with  a  library 
approach.  Research  areas  include  exploring  ways  to 
decompose  problems  to  determine  appropriate 
domain  classifications  and  the  most  effective 
methods  of  reuse.  'Hie  domain-oriented  life  cycle 
then  allows  developers  to  "capture  and  reuse  domain 
specific  ,  knowledge  across  applications,  tncrcbv 
accelerating  and  rendering  manageable  the  infamisil 
process  of  reuse  that  currently  occurs." 

As  can  be  observed  from  this  summary.  Simos’ 
approach  is  pnmanly  concerned  with  development, 
lie  makes  no  mention  of  the  V&V  phases  of  the 
luc-cyele. 


The  Reusability  Guidebook"  is  a  compilation  of 
the  major  issues  related  to  reusability  being  studied 
by  the  Ada  community,  h  does  not  specifically 
address  the  issues  of  verification  and  validation 
although  it  docs  refer  to  terms  such  as  software  test¬ 
ing  and  proofs  of  correctness.  None  of  these 
occurrences  directly  relate  to  the  V&V  of  reusable 
components.  ’Hie  main  points  mentioned  in  the 
document  were  the  following  1)  because  reusable 


components  would  be  heavily  used,  ihcv  should  thus 
be  tested  more  thoroughly,  and  2)  the  fact  that  they 
arc  used  more  and  in  more  varied  environments 
would  eventually  result  in  more  reliable  products. 

An  important  issue  that  is  pointed  out  by  the 
Guidebook  is  that  there  arc  three  different  types  of 
individuals  who  arc  involved  in  the  rcysc  cifort. 
'Ilicy  arc  tire  parts  manufacturer,  the  parts  user,  and 
the  librarian.  Tarts  manufacturers  have  to  verify  and 
validate  tlicir  products  with  greater  care  since  tl»ey 
arc  likelv  to  be  used  in  a  large  number  of  application 
and  machine  environments,  and  the  success  of  reuse 
will  largely  depend  upon  the  confidence  that  the 
users  will  have  on  the  reusable  pahs.  The  parts  user 
should  only,  (once  the  applicability  of  the  part  is 
understood),  have  to  be  concerned  with  integration 
(black  box)  testing  of  the  different  parts.  The 
librarian  should  have  a  well  understood  way  of 
accepting  or  rejecting  submitted  pans. 

A  point  made  in  the  Guidebook  is  the  need  for 
metrics  of  reusability.  The  metrics  should  cover 
concepts  such  as  a  measure  of  confidence  that  a  new 
user  of  a  previously  developed  pan  may  reasonably 
apply  to  the  suitability  of  a  pan  for  a  potential  new 

S'lcadon.  There  should  also  be  metrics  of  the 
pcndencc  of  the  pan  from  the  host  and  target 
computer.  Funltcnnorc,  metrics  measuring  charac¬ 
teristics  such  as  coupling,  cohesion,  reliability, 
modifiability,  localization,  protection  against 
incorrect  usage,  and  error  handling  are  also  impor¬ 
tant  and  could  be  usctl  to  determine  the.  adequateness 
of  a  part. 

Although  there  are  some  well  known  metrics 
that  can  be  used  to  measure  characteristics  such  as 
coupling  and  cohesivencss.  some  of  the  other  charac¬ 
teristics  mentioned  do  not  have  adequate  or  generally 
accepted  measures.* 

The  issue  of  liabilities  and  warranties  is  also 
explored  by  the  Guidebook.  'Hie  point  is  made  that 
a  developer  might  be  reluctant  to  reuse  pans  if  he  or 
she  will  be  liable  for  failures  of  subsequent  reuse. 
The  part  developer,  the  Guidebook  suggests,  would 
be  responsible  for  guaranteeing  that  the  pan  meets 
its  original  specification.  'Hie  user  of  reusable  parts 
would  be  responsible  for  die  developed  product, 
within  the  limits  of  any  warranties  which  may  exist 
from  the  original  developers  of  the  incorporated 
parts.  There  arc  three  categories  of  ownership  of 
parts:  Government  ownership,  mixed  ownership, 
and  private  ownership.  Under  Government  owner¬ 
ship,  use  of  parts  is  optional  and  any  user  accepts 
full  responsibility  for  the  use  of  the  part.  Under 
mixed  ownership  liability  is  governed  by  the  terms 
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of  a  license  agreement,  and  the  owner  accepts 
responsibility  for  meeting  the  part  specification. 
Under  private  ownership  liability  is  governed  by  the 
terms  of  a  license  agreement. 

Software  pans  are  normally  designed  in  the  con¬ 
text  of  a  particular  method  such  as  object-oriented 
design  or  functional  decomposition.  Parts  designed 
based  on  a  single  paradigm  have  certain  distinct 
advantages-  over  the  multiple  paradigm  approach. 
The  Guidebook  notes  advantages  of  designing  pans 
based  on  a  single  paradigm.  Specific  goals  men¬ 
tioned  in  the  Guidebook  am  the  following:  I)  uni¬ 
formity  of  interface  comprehension,  2)  simplification 
of  intra -component  comprehension,  ?)  simplification 
of  part  development  and  maintenance,  and  4) 
simplification  of  part  testing  and  optimization  for 
automated  testbed  generation. 

The  Guidebook  states  that  integration  of  parts  in 
unanticipated  ways  requires  a  larger  testing  effort. 
Part  of  any  reusability  effort  should  go  into  develop¬ 
ing  a  well  supported  mechanism  to  integrate  reusable 
parts.  Unfortunately,  the  Guidebook  is  unable  to 
define  a  methodology  to  achieve  such  objectives. 

Several  other  points  are  made  in  die  Guidebook 
that  are  worth  commenting  on  here. 

+  "The  use  of  proven  parts  can  reduce  levels  of 
dcvclopnxmt  effort  and  test  and  integration  time 
through  fewer  errors  and  will  result  in  more  reli¬ 
able  products." 

Even  though  this  is  a  logical  statement,  it  is  impor¬ 
tant  to  realize  that  parts  still  need  to  be  used  for 
their  original  purpose  and  that  if  tiicy  are  not,  they 
may  be  die  ones  causing  die  "faults"  in  die  system. 
Assuming  that  they  arc  correct  under  any  cir¬ 
cumstance  can  only  create  problems. 

+  'The  use  of  proven  pans  can  reduce  levels  of 
dcvclopntcnt  effort.” 

'ITtis,  of  course,  is  dependent  whether  die  part  is 
being  used  in  a  way  anticipated  by  the  original 
developers  and  on  how  much  edaptation  needs  to  be 
performed. 

+  ’Testing  is  facilitated  by  use  of  one  intensively 
tested  generation  piece."  Once  this  piece  is 
trusted,  only  variable  parametric  attributes  of  each 
instance  need  to  be  tested  further. 

It  may  not  be  possible  to  parameterize  all  of  the 
desirable  dimensions  of  reuse,  at  lease  where  Ada 
generics  art  concerned. 


Conclusions  and-Rccemmcndattons 

Traditional  software  life  cycle  models  do  not 
address  die  topic  of  reuse.  Those  people  who  have 
considered  the  issues  of  reuse  have  largely  concen¬ 
trated  on  the  implementation  phase  of  software 
development.  We  believe  that  incorporating  stages 
into  life  cycle  models  where  the  primary  motivation 
is  tlw  design  or  incorporation  of  reusable  com- 
l>oncnts  would  be  highly  beneficial.  We  also  believe 
dial  some  of  the  labor  intensive  activities  involved  in 
incorporating  reuse  could  be  automated  by  a 
software  development  environment.  Although  some 
attention  has  lately  been  paid  to  the  reuse  ordcsigns, 
we  are  not  aware  of  any  discussion  of  the  relation  of 
reuse  to  the  V&V  activities  of  die  software  develop¬ 
ment  life  cycle. 

When  reuse  is  a  consideration,  V<£V  activities 
becomes  more  complicated.  11k  complications  arise 
from  differences  between  die  environment  for  which 
a  component  was  developed  and  drc  oik  in  which  it 
will  be  reused.  Environmental  differences  derive 
front  different  hardware  architectures,  compilers, 
run-time  systems  and  from  different  application 
environments  and  usage  patterns.  Traditional  V&V 
treats  these  issues  as  non-functional  requirements. 
Conventional  testing  techniques  are  constrained,  to 
detecting  differences  between  functional  requirc- 
ments  and  actuat  program  behavior  and  therefore  can 
not  be  applied  to  non-functional  requireiiKtits. 

To  deal  with  these  problems,  traditional  func¬ 
tional  specification  techniques  need  to  be  extended  to 
deal  with  these  environmental  issues.  The  first  step 
to  accomplishing  this  is  to  characterize  the  environ¬ 
mental  constraints  lhai  may  affect  the  behavior  of  a 
component.  Such  a  characterization  includes 
language  issues  and  a  discussion  of  application 
environment  issues  such  as  synchronization  and 
memory  management.  A  description  of  an  initial 
characterization  lias  been  given  in  a  separate  paper.* 
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A  logic  framework  for  version  control  and 
configuration  management  of  Ada  programs  Is  pro* 
posed.  The  paper  describes  the  motivations  and  benefits 
of  our  approach  and  shows  how  cross-referential  and 
dependency  Information  can  be  abstracted  from  Ada 
compilations  to  support  version  and  configuration 
management.  A  prototype  logic-based  program  library, 
in  plcmcntcd  in  the  logic  programming  language  Pro¬ 
log.  is  also  described. 


lninsluoieo. 

The  paper  describes  a  new  program  library  structure  for 
Ada  based  on  a  logical  framework  for  version  arul  configuration 
management  of  software  components.  Prototype  tools,  written  in 
Prolog,  for  extracting  Infomtatlon  from  a  panted  program,  for 
creating  new  versions  of  a  program,  and  for  storing  the  informa¬ 
tion  In  the  proposed  program  library  arc  described.  Before  look¬ 
ing  more  closely  at  the  program  library  and  associated  tools  we 
discuss  the  general  Ada  compilation  philosophy  and  outline  some 
of  the  limitations  of  existing  approaches  to  configuration  manage¬ 
ment. 


The  programming  language  Ada  allows  programs  to  be  put 
together  from  a  number  of  source  texts  that  have  been  compiled 
separately.  The  text  compiled  on  a  single  occasion  is  known  ns  a 
compilation.  Each  compilation  is  a  collection  of  one  or  more 
compilation  unlu.  A  compilation  unit  is  a  separately  compiled 
specification  or  body  of  a  subprogram  or  package,  or  a  subunit. 

A  compilation  unit  Is  either  a  library  unit  or  a  secondary 
unit,  A  library  unit  is  a  compilation  unit  (which  is  a  self- 
contained,  independent  module)  that  can  act  as  a  reusable 
software  component  or  a  building  block  for  oilier  software  pro¬ 
jects.  A  self-contained  compilation  unit  is  one  that  sliould  not  be 
dependent  upon  anotlicr  module  or  data  structure  as  far  as  possi¬ 
ble.  A  library  unit  is  a  subprogram  specification,  a  package 
specification,  a  generic  specification,  a  subprogram  body,  or  a 
generic  instantiation.  Each  library  unit  must  have  a  simple  name 
that  is  a  distinct  identifier. 

A  compilation  which  is  a  subprogram  body  is  interpreted  as 
a  secondary  unit  if  die  program  library  contains  a  unit  with  the 


same  name.  It  Is  oUtcrwIsc  interpreted  both  as  a  library  unit  and 
as  the  corresponding  library  unit  body  (that  is,  a  secondary  unit)'. 
The  effect  of  compiling  a  compilation  unit  that  is  a  library  unit  is 
to  define  (or  redefine)  it  as  one  that  belongs  to  the  program 
library. 

A  secondary  unit  is  ciilicr  the  separately  compiled  proper 
body  of  a  library  unit,  or  a  subunit  of  another  compilation  unit. 
The  effect  of  compiling  a  compilation  unit  that  is  a  secondary 
unit  Is  to  define  the  body  of  a  library  unit.  The  effect  of  compil¬ 
ing  a  secondary  unit,  as  a  subunit,  is  to  define  the  proper  body  of 
a  program  unit  llut  is  declared  within  another  compilation  unit. 

The  secondary  unit  (implementation)  of  a  library  unit  can  be 
compiled  and  added  to  die  program  library  at  a  later  time.  This 
means  that  Hie  Implementation  of  a  library  unit  (such  as  the  body 
of  a  subprogram  or  package,  or  subscqucmly  a  subunit)  can  be 
ehanged  repeatedly  without  affecting  any  software  that  makes  use 
of  tlie  library  unit 

Subunits  can  be  used  to  decompose  a  large-scale  software 
project  Into  manageable  software  components  the  implementation 
of  which  can  bc-dcferred  to  a  later  time.  This  type  of  software 
development  supports  die  use  of  structured  design  techniques. 
By  compiling  a  compilation  unit  that  contains  a  number  of  stubs  ( 
that  are  specifications  of  program  units),  die  compiler  will  be 
aware  dial  some  implementations  will  follow  at  a  later  time  and 
may  be  stored  in  different  files.  A  subunit  construct  has  a  number 
of  advantages.  There  are: 

•  it  provides  support  for  top-down  development 

•  entities  of  a  subunit  compilation  can  be  taken  down  to 
any  level  required,  enabling  die  developer  to  design 
the  software  structure  more  accurately. 

•  it  can  make  use  of  library  units,  Uius  reducing  die 
number  of  dependencies. 

Information  concerning  a  compilation  unit  is  added  to  a 
program  library  when  it  successfully  compiles.  Compilation  units 
stored  in  die  program  library  can  be  used  as  components  of 
several  programs.  A  program  library  is  a  database  for  software 
development,  therefore  any  separation  of  it  from  tlie  software 
environment  tools,  can  be  considered  to  be  impractical  for  large- 
scale  projects. 

TliC-Maiii-Program. 

All  compilation  units  of  a  program  must  be  stored  in  one  or 
more  program  libraries.  These  compilation  units  are  invoked  by 
means  of  a  main  program  unit  diar  will  link  together  all  library 
units  required  to  configure  a  software  system.  Ada  requires  lliat 
the  root  of  cv"  software  system  be  a  subprogram,  since  it 
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represents  an  algorithmic  attraction.  Main  programs  art  subpro¬ 
grams  that  are,  at  kasi,  paramctcricss  procedures.  A  main  pro¬ 
gram  must  be  a  library  unit.  An  Implementation  may  impose  cer¬ 
tain  requirements  on  the  parameters  and  on  the  result.  If  any,  of  a 
main  program. 

In  our  case*,  a  main  program  unit  Is  defined  to  satisfy  the 
following  conditions: 

1.  it  Is  a  subprogram  body, 

2.  it  is  the  root  of  a  software  system,  and 

3.  it  is  parameterkss  *• i 

YislhiUtx^LcofDptlaiiaumiti. 

Ada  encourages  the  development  of  self-contained  modules. 
These  modules  act  as  ready-made  components  for  future  re-use; 
hence  an  easy  and  flexible  approach  to  Incorporating  these 
modules  Is  required.  Ada  provides  two  constructs  to  make 
modules  visible  to  other  software  components  that  need  to  use 
them.  These  constructs  arc: 

I-  w Uh-clauscs.  and 

II-  use-clausa. 

With- clous  a  express  relationships  between  compilation 
units.  They  specify  which  library  units  are  being  used  or  which 
other  compilation  units  arc  necessary  for  the  execution  of  a  given 
unit  within  which  the  clause*  apf-car.  They  also  enable  the  com¬ 
piler  to  check  the  use  of  Were  library  units  (listed  in  uV  with- 
clausa)  In  the  submitted  compilation  against  their  specification  In 
the  program  library. 

The  second  construct,  use-clause,  Is  used  only  with  package 
units  and  enables  package  exports  to  be  referenced  directly  by 

their  names  in  the  program  unit  under  consideration.  If  use-clause 
is  not  specified  the  syntax 

<  name-of-packago .  <  namc-of-export> 

would  have  to  be  used  for  every  applied  occurrence  of  an 
export.  The  use  of  with-clausa  and  use-clausa  is  an  aid  to  writ¬ 
ing  programs  that  arc  readable  and  cully  maintainable. 

Software  products  have  been  applied  to  many  complex 
problems  in  tlie  software  industry  throughout  the  1970's. 

Many  of  these  products  have  failed  over  the  last  decade5.  In 
response  to  these  failures  more  attention  lias  been  given,  within 
die  software  engineering  community,  to  methods  towards  tire 
automation  of  software  configuration  management. 

Software  Configuration  Management  (SCM»  has  been 
defined  by  IEEE  standards'°as  the  process  of: 

•  Identifying  and  defining  the  configuration  items  in  a 
system 

•  controlling  tltc  release  and  change  of  Oicee  items 
throughout  tltc  system  life  cycle 

•  recording  and  reporting  the  status  of  configuration 
items  and  change  requests 

•  verifying  die  completeness  and  correctness  of 
configuration  items. 

*Ad«  Conpiki*  und«  UNIX. 


The  fundamental  features  of  SCM  are 

I-  the  Identification  of  components  of  a  software  product 
?•  the  build  dependencies  inherent  in  each  component 

3-  the  build  rules  to  derive  or  rcdcrive  executable  code 
from  source  code. 

Most  existing  software  configuration  and  version  manage¬ 
ment  tools  have  the  following  limitations: 

•  only  source  code  is  covered  by  the  storage  and/or  control¬ 
ling  schemes.  No  provisions  arc  made  for  incorporating 
other  objects  such  as  specifications,  documentation,  or  user 
requirements 

•  tire  possible  relationships  between  versions  of  a  module  arc 
limited  in  type  and  generally  fixed  in  number 

•  It  Isn't  possible  to  incorporate  different  styles  of  version 
management  In  different  projects  within  an  organisation, 
and 

for  Ada,  what  tools  exist  have  the  following  drawbacks: 

•  integration  between  a  program  library  and  Urn  environment 
tools  is  difficult  and  inflexible 

•  lhc  program  library  is  complex,  restrictive,  and  lacks  porta¬ 
bility 

•  each  Implementation  has  its  own  environment  tools  that  can 
not  be  used  by  other  Implementations.  The  Ada  program¬ 
ming  language  is  portable  and  so  the  environment  tools 
should  also  be  portable 

•  dependencies  ml  relaiiomh!(*  between  configuration  com¬ 
ponents  and  versions  are  not  computed  automatically  from 
the  Ada  source  fik.  Por  example,  in  tire  DSEE  system,  lire 

user  has  to  provide  dependency  relationships  among  com¬ 
ponents1. 

The  proposed  version  and  configuration  management  system 

alms  to  overcome  tire  above  drawbacks  by  providing: 

•  the  power  to  incorporate  intelligence  in  browsing  and  in 
command  Interpreting,  along  with  a  consistent  representation 
of  knowledge  and  data, 

•  a  deductive  capability  of  producing  new  facts  from  existing 
ones.  A  prototype  implementation  has  been  written  in  Pro¬ 
log,  which  unlike  relational  databases,  provides  an  inference 
mechanism  "•  *2, 

•  a  portable  program  library,  which  depends  only  on  the  Ada 
syntax  rules  as  defined  by  die  Ada  Reference  Manual.  It  is 
implemented  using  an  Ada  parser  written  in  Prolog,  front 
whieh  the  necessary  facts  are  extracted  and  stored  in  tire 
program  library, 

•  a  complete  Integration  between  die  program  library  and 
configuration  and  version  management  model, 

•  die  possibility  of  having  more  dian  one  program  library 
such  diat  dierc  can  be  9,  high  interaction  amongst  diem, 

•  an  automatic  computation  of  compilation  and  recompilation 
dependencies  from  die  Ada  source  code  through  die  parser, 

•  a  way  to  compile  new  versions  witliout  interpreting  diem 
as  a  recompilation  unit, 

•  a  capability,  sucli  dial  when  a  program  unit  has  been 
modified  an  automatic  request  is  generated,  to  modify  all 
units  affected  by  diis  modification.  For  example,  if  a 
specification  of  package  is  modified  dien  an  automatic 
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request  to  modify  in  dependencies  ( l.e  Its  body  and  u  a 
cons'  juence  the  affected  stub  units  of  the  modified  body)  is 
issued. 

•  a  suitable  method  for  expressing  software  component  func¬ 
tionality  for  the  purpose  of  re-use.  Boehm  7  has  suggested 
that  very  significant  improvements  In  software  productivity 
will  only  be  seen  when  software  re-use  is  widely  practised. 

•  a  simple  and  efficient  way  of  deleting  old  Information, 
adding  new  information,  and  issuing  queries  about  com¬ 
ponent  names,  types,  storage  locations,  version  numbers, 
time  of  ftrst  compilation,  number  of  recompilations  with 
dates,  and  so  on,  and 

•  a  reduction  in  the  sire  of  the  necessary  code  for  building  a 
programming  support  environment  or  version  control  and 
configuration  management  tools*. 

BttottamJLlbfaa 

A  basic  structure  for  CM  for  Ada  it  the  program  library.  A 
prototype  program  library  has  been  designed  *•  *  to  act  as  a  data¬ 
base  for  Of.  The  components  of  a  program  library  represent 
Stnrctui.M  within  the  software  system  being  developed.  These 
structures  can  be  viewed  as  a  act  of  components  and  a  set  of  logi¬ 
cal  relationships  and  dependencies  between  the  components.  A 
logic  programming  language  seems,  therefore,  an  appropriate  tool 
which  can  be  used  to  express  these  logical  relationships  and 
dependencies. 

We  believe  that  this  prototype  program  library  olfers  a 
(inn  base  for. 

•  building  a  more  efficient  and  flexible  version  and 
configuration  management  system  for  the  Ada  pro¬ 
gramming  language, 

•  expressing  the  functionality  of  the  components  of  a 
library, 

•  portability,  because  it  depends  on  the  grammar  rules  of 
Ada  as  defined  in  the  Ada  programming  Reference 
Manual. 

The  program  library  Is  created  using  the  following  tools: 

•  an  Ada  parser  written  in  the  logic  programming 
language  Prolog. 

•  the  tool  'makelib'  to  insert  the  facts,  extracted  from 
the  parsed  Ada  program,  into  the  program  library. 

Dependencies  and  relationships  between  configuration  com¬ 
ponents  and  versions  are  com  puled  automatically  from  lire  Ada 
source  file. 

The  current  Implementation  lias  a  tool  'crcate.verslon’  to 
create  new  versions  of  a  component  by  automatically  copying  or 
inlieriiing  values  of  properties  (  i.c  attributes)  from  a  previous 
version  onto  Use  new  created  version.  When  a  version  of  a  com¬ 
ponent  ( or  compilation  unit)  is  created  from  scratch  then  tire  tool 
'crcatc_vcrsion'  calls  up  the  tool  'makelib'  to  parse  tire  com¬ 
ponent  source  code  so  that  tire  necessary  information  can  be 
extracted  and  stored  in  tire  program  librwy.  This  program  library 
is  similar  to  arty  text  file  under  UNIX.  The  information  extracted 
by  the  tool  ’makelib*  is  represented  by  tire  following  facts: 

1-  type  of  compilation  unit  such  as: 


packag«jq>f<iHcatlon(  Compiiatlon.Unit). 
package J>od>(  Cowpilatkm.Unlt). 
subprcgram_spcciflcatkm(  CompUatkmJJnU). 
subprogram_body(  Compilalion.Unlt). 
genericjqtcci!lcatk>n(  Compilatkm.Unit). 
generk_lnstantlation(  Coropililion.Unit). 

2-  dependencies  such  as: 

partwIJMiltf  P»rt»(.Upt<.N»*»».  }!»li_V>»t«.N»«Wf ), 

with.cUwKf  t.Ht_Of.U»Sts,  t)vfT«Ht<Plml!pit). 

3-  other  useful  Information  such  as: 

eompostdLoff  Compilatlon.Unlt,  Ust_Of_Unhs). 

compowd.of  Is  a  fact  that  shows  the  program  units  constituting  a 
compilation  unit. 

The  tool  'crcate.verslon'  also  provides  a  mechanism  to  add 
new  information  to  the  existing  program  library.  This  Information 
Includes  the  following  sample  of  fxts: 

un!t(  optimise,  0ptimiKl9M3lll2345, 
subprogramjxrdyf  optimise,  optlmlwlWUI  112345)). 

flle.namcf  xubpn>gram„bady3UI234$, 
subpnrgram.body(  optimise,  optlmiarl9fW31 1 1234$)). 

dalt<  opUmli*I*W31II234$,  |  1MX,  'Oct',  31,  II,  23, 

«)). 

syslttiK  opllmiaeim3l 11234$, '  UNIX’). 


language^  optimi*cim31U2345, » Ada'). 
debug(  optlmls*l**3l  11234$,  reliable). 
siate(  optlmlrelMtUl  1 12345,  undetermined). 
IhcJtosionJ'lodd 

During  tire  development  and  maintenance  of  a  software  pro¬ 
duct  a  number  of  versions  of  a  particular  module  (specification) 
are  generally  produced.  Different  versions  may  be  alternatives  or 
variations  that  are  applicable  to  different  operating  environments 
or  systems  or  they  may  be  revisions  which  are  successive 
attempts  to  Improve  an  implementation.  Multiple  versions  may 
also  esist  for  otitcr  reasons  ( for  example  a  debug,  a  high  speed/ 
Irlgh  storage  version)  where  the  versions  bear  no  chronological 
relation  to  each  other. 

We  aim  to  encompass  any  relationship  or  set  of  version 
attributes  that  may  be  required,  and  do  not  impose  any  of  the  lint- 
itations  which  exist  in  other  version  management  systems. 

Tire  value  of  a  logical  framework  for  version  management 
Is  that  it  allows  the  user  to  reason  about  versions  and  to  query  the 
version  database  to,  for  example,  identify  a  specific  version  of  a 
module,  or  discover  tire  relationships  between  all  existing  ver¬ 
sions  of  a  particular  module.  For  example,  one  can  find  the  ver¬ 
sion  which  is  derived  from  one  of  tire  versions  of  the  compilation 
unit  'optimise'  with  tire  lime  attribute  constrained  between  Time! 
and  Timc2. 
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t}< rl% cd.frtMW (  ComplUtkm.Uiill,  Ncw_Vcrsl<m,  Tint»2|):- 

ur»tt(  Compllition.ilnll,  (Md_Vmlon,  j, 
cople«Utom(  Ncw.Vcrsfcm,  Old_Vcrs»on), 
datt{  Ntw_Vcr*ion,  Time), 

Tlme<Tln*l, 

Time  >  Timet 

Deleting  version*  of  an  object  can  easily  be  achieved  by 
searching  for  the  required  version  citlter  by  giving  its  full  struc¬ 
ture  or  It  including  some  of  Its  attributes.  Tor  example: 


deletef  Version,  Time)  :• 

date!  Version,  Y), 

Y  »  Time  , 
remosef  Version). 

11)1$  approach  also  provides  a  basis  for  managing  tire  proli¬ 
feration  of  versions  during  die  course  of  a  project.  Automated 
clean  up  support  can  be  provided.  I:or  example,  one  could  delete 
all  but  a  designated  'most  recent'  version,  or  ail  versions  created 
before  a  specified  time  or  within  a  period  of  time  or  all  versions 
with  a  particular  set  of  attribute  values.  In  fact,  any  policy  or 
convention  that  can  be  expressed  as  a  role  could  be  enforced.  It 
might  also  be  desirable  to  implement  a  policy  whereby  attributes 
of  an  object  could  be  modified  without  creating  a  new  version. 

the  propored  fiamcw-otV  covers  not  just  source  code  but 
Incorporates  other  objects  in  tire  software  engineering  life  cycle 
such  as  user-requirements,  specifications,  and  design.  For  simpli¬ 
city.  within  ojr  prototype  implementation,  user-requirements, 
specifications,  and  desiens  are  made  available  through  an  object 
called  description.  As  many  revisions  of  the  object  description  as 
required  can  be  created.  These  revisions  arc  linked  directly  to  tiic 
source  code  ( implementation)  revisions  through  the  fact: 


fcKrlpdMi.tprct  DmilfllM,S«KlN,  C«4»Jt*»Wo«). 

It  Is  possible  to  issue  any  query  regarding  description  rcvi< 
sion  and  code  revisions.  For  example,  one  can  issue  a  query  such 
as: 

list  oil  eode  revisions  of  description  version  'deserty- 
iionwmm-tsir 
The  answer  w-ould  be: 

rutitr.qnlfnilM 

CIlrnilr.SvM.MrflmlVI'rrale.SwxOlHlKiUlMaUIIISS:'! 

pKkBgt.SfttMoOM 

Clkralt.$«M.Mt<M7l*(r<l<.!>tt>ii.M«lHi4tMUUIIUISl'l 

pwkagr.kodf 

t'licr»lr.S*«ii..M*tko4',,l(«»if.S«*»..MttlK«llHttll»7trj') 

pxki(r.koU]r 

Cllfr«U.S»»«.'ink«t7]|<r»k.SwiOtnkodlHK»JWI3J') 

rKkin.Mf 

t'lltnil».S»*n.M«lkod,,'II»r»k.S>*»».M«lko<S|H*}eil2Wn 

pxktcr.boUjr 

ClUr»lf_S><«n_Mtlliod7lttr«lfj;><«ii_M<lKwll»tUI  I1HI2') 

from  lire  d.tabasc  set  of  facts  and  the  logical  relationships 
rival  exist  between  compilation  units  and/or  program  units  of  die 


Ada  programming  language,  one  an  deduce  new  facts  from 
existing  ones,  delete  old  information,  add  new  information,  and 
issue  queries  about  component  names,  types,  storage  locations, 
version  numbers,  time  of  first  compilation  or  recompilation  with 
dates.  For  example,  one  can  define  a  main  unit  using  the  follow. 
Ing  rule: 


malnf  Unit)  :•  subprogramJxKlyf  Unit), 
root.of.sjstcmf  Unit), 
paramdcrlcuf  Unit), 
or  issue  the  following  query: 

whin  are  the  versions  of  the  component  'Complcxjtelaiont'  that 
were  trotted  on  31  October  I9SS  m  or  after  half  past  nine  In  the 
morning  ? 


1 7-  uttllf  'CompIcx.RcUitons',  Version,  Type), 
dalef  Version,  Dale), 

Date  ■  (  IflK,  ’Oct*,  31,  II,  M,  J, 

II  >  »,  M  >»  30. 

Version  n  'CompkxJt*l»iJo«|j«JUIP4IM', 

Type  a  paekage_specili«alion(  'Complex.llelallonx', 
'Complex_Relatlonsl9tNUINI44'). 

one  could  ask  “where  Is  tire  above  version  stored?” 

1 7-  Ble.aawri  file,  'Compttx.Wtktlon  ISMJIH  l*4‘). 

File  >  spec311Ml-M.ll 

Tlic  current  prototype  system  has  a  capability,  such  that 
when  a  program  unit  has  been  modified  a  request  to  modify  ail 
units  affected  by  this  modification  is  generated.  For  example.  If  a 
specification  of  a  unit  is  modified  then  an  automatic  request  to 
modify  its  dependencies  is  issued.  Two  ways  of  notifying  the 
user  are: 

1.  relying  on  the  user  to  issue  a  query: 

“display  die  program  units  that  constitute  Die  modified  com¬ 
pilation  unit  'Complex_Relatior«'“ 

|  ?•  compottd.off  body(  'Complex.Rclailont*,  J,  list). 

‘Die  answer  would  be: 

List  ■  [  subprogram_stub( sqr,  sqrl988)6l21309), 
subprograin.stubf  divide,  divldcl988l832l2-t5). 
subprogtam.stubf  scatmuh.  $calmultl988IOS923-l), 

| 

2.  automatially: 

for  example,  when  a  new  version  of  rite  package 
specification  'Comp!ex_Rclxions‘  is  created  using  die  tool 
'crtaie_venion*  as  follows: 


472  7th  Annual  National  Conference  on  Ada  Technology  1989 


|  7  crt»!c_vm!ofi(  ’CoropWxJlcUiions’). 

ihc  UKf  1$  automatically  notified  of  the  dependencies  by  a 
response  such  as: 

'Please  remember  to  modify  the  corresponding  body  which  it 
stored  in  the  file  'comp.rei.A* 

When  the  file  'comp.rcl.A’  1*  modified  a  request  is  also  gen¬ 
erated  to  modify  its  stubs: 

'Hesse  remember  to  modify  the  stubs  of  the  modified  body 
which  sre  stored  in  files  'rcst»comp.A\  ‘sqr.A*  *. 
then  the  system  asks: 

“Would  you  like  to  edit  these  files  7  ( yAt):  * 

Other  version  or  object  meta-tnformation  that  could  be 
recorded  includes  the  reasons  for  its  creation,  the  reasons  for  its 
deletion,  ownership,  derivation,  and  other  statistical  data.  This 
information  can  be  stored  in  the  database  as  facts  in  the  fomt: 


erntioof  Object,  Why), 

«Wetioo(  Object,  Reasons), 

derivatfonf  Object,  Information), 
modl!kallon(  Object,  Modify), 
etherf  Object,  Other), 

Tbit  information  could  be  useful,  for  example,  for  tracing  the  Ids* 
lory  of  the  Implementation  of  a  particular  program  specification, 
in  fxt  systems  that  maintain  this  sort  of  information  have  proved 
useful  in  the  past1.  Babich11  reports  that 

“many  times  the  fastest  approach  to  finding  a  bug  is 
not  analysis  of  the  program  itself,  but  analysis  of  the 
history  of  the  program  •  how  it  was  created". 

Meta  data  may  record  Use  textual  derivation  of  an  object  or 
version.  This  could  provide  valuable  information  for  stooge  algo* 
rithms  which  attempt  to  minimise  the  storage  requirements  of 
multiple  versions  of  program. 

Other  possible  queries  about  versions  are: 

list  all  versions  of  library  unit  X. 

what  are  the  components  of  a  program? 

find  the  stubs  of  a  ccnaln  body  unit. 

find  all  versions  of  secondary  unit  Y  that  are  created 

between  time!  and  limeZ, 

and  so  on. 

This  information  will  permit  the  building  of  portable  ver¬ 
sion  control  anti  conjuration  management  tools  since  the  pro¬ 
gram  library  itself  is  portable. 

ConfiguutictijiL&jlaLj  tcJJyscffli. 

The  Ada  programming  language  is  designed  to  support 
separate  compilation  for  constructing  large  programs  and  creating 
program  libraries  of  precompiled  components.  Compilation  units 
can  be  compiled  in  any  order  as  long  as  the  checking  of  con¬ 
sistency  between  the  compilation  units  and  code  generation  is 
observed. 

Our  prototype  configuration  manager  automatically  compiles 
an  Ada  system  (  program)  according  to  Use  roles  governing  die 
dependencies  of  compilation.  When  a  compilation  unit  is  submit¬ 
ted  to  the  compiler,  all  its  dependencies  arc  identified  and 


compiled  accenting  to  Ada  roles  *.  A  preset  condition  ( or  a  set 
of  conditions)  is  used  to  govern  the  selection  of  the  required  ver¬ 
sion  or  set  of  versions  of  exh  compilation  unit. 

The  selection  criteria  can  be  variable,  fixed,  or  under  user  or 
manager  consrol.  xeordlng  to  local  needs.  The  following  code  is 
an  example  set  of  conditions  for  selecting  a  particular  version  of 
a  compilation  unit. 


OovftWitw^ynh,  Kfwa.T)»<l,T«.ThR<a):. 
dateC  CompiUtfon.Unll,  Time), 

Time  >  Krtmt.Tlmtl, 

Time  <  To_Timt2, 
stalef  Compitatlon.Urdt,  good), 
language  CompUation.Unlt,  'Ada'), 
dtbugf  CompilaTion.Unil,  reliable). 

A  *Compilation,.UnIi*  C  c*  set  or  units)  is  xlectcd  if  it  is 
created  between  time  Trom_Timel‘  and  *To_*fime2' ,  its  state  is 
good,  it  is  wrinen  in  Ada  (  versions  of  modules  written  in 
languages  other  than  Ada  could  be  incorporated),  and  It  Is 
believed  to  be  reliable. 

If  no  version  satisfies  (he  preset  condition  then  either  a 
request  can  be  Issued  for  permission  to  use  a  default  version,  or 
"missing  compilation  unit*  Is  simply  reported.  The  current  Implc* 
menu1  ion  allows  defaulting  to  either  ‘preferred*  version  or  to  the 
■latest*  version  bur  any  logical  role  could  be  imposed,  it  also 
incorporates  version  priorities. 

When  a  compilation  unit  is  modified  and  then  recompiled, 
tlx  whole  Ada  program,  of  which  it  is  a  component,  does  not 

have  to  be  recompiled.  The  units  that  need  to  be  recompiled  arc 
identified  according  to  the  following  role*: 

•  A  library  unit  requires  the  recompilation  of  all  tlx 
compilation  units  that  depend  upon  (  i.c  use)  this 
library  unit. 

•  If  a  compilation  unit  is  not  a  library  unit  and  consists 
of  a  pxkagc  body  or  subprogram  body,  it  only 
requires  the  recompilation  of  tlx  subunits  declared 
within  it*  body.  Other  compilation  units  which  use  the 
modified  compilation  unit  do  not  need  lu  be  recom¬ 
piled.  because  they  do  not  depend  upon  tlx  implemen¬ 
tation  of  the  package  or  subprogram  My. 

•  A  subunit  docs  not  require  the  recompilation  of  a 
parent-unit  or  any  otlxr  subunits. 

When  a  unit  is  submitted  to  a  compiler,  tlx  CM  system  will 
search  tlx  database  for  it.  If  a  unit  with  tlx  same  name  lias 
already  been  compiled  then  the  system  will  take  a  recompilation 
action,  odxrwisc  it  will  take  compiling  action.  For  tlx  recompila¬ 
tion  action,  tlx  system  will  automatically  recompile  all  tlx  neces¬ 
sary  units  according  to  Ux  Ada  recompilation  roles.  Wixn  a  com¬ 
pilation  unit  successfully  compiles  tlx  proposcJ  configuration 
manager  stores  its  type  as  a  fact  in  tlx  form: 


compilcdf  subprogramjrodyf  optimise,  optim- 
1x1988101 11234)). 

This  additional  information  about  a  compiled  unit  allows 
new  versions  of  a  unit  to  be  represented  without  them  being 
treated  as  recompilau'on  units  (  and  lienee  replacing  the  version  in 
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use).  A  preset  condition  an  xlso  be  tied  to  govern  the  selection 
of  the  appropriate  version  for  recompilation. 

CCOCluslCDt 

Software  con (1  gyration  management  and  version  control  Is 
an  Important  aspect  of  software  engineering.  It  provides  the 
means  of  identifying  the  components,  and  the  relationships 
between  components,  of  a  system  at  any  point  In  time.  This 
allows  the  systematic  control  of  changes  to  a  configuration  and 
pmvIJc*  overall  control,  visibility,  and  traceability  of  a 
cmirtfuratioo  throughout  the  life  cycle  Of  a  software  system. 

A  logical  structure  for  the  Ada  program  library  and  the 
configuration  of  vcrslosw  has  been  proposed.  This  structure  Is 
created  using  an  Ada  programming  language  parser  written  in  the 
logic  programming  language  Prolog.  The  Input  lo  the  parser  Is 
the  Ada  source  file.  Useful  facts  arc  attracted  from  the  parsed 
program  and  written  in  the  proposed  program  library  using  tools 
written  In  Prolog.  This  proposed  system,  we  believe,  provides 
the  flexibility  required  to  tackle  the  issues  described  above. 
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DESIGNING  FOR  CHANGE  :  AN  ADA  DESIGN  TUTORIAL 
Jims  A.  Hager 

HR8  -  Systems  Inc. 


Abstract 

Sixty  percent  of  the  software  costs  associated 
with  the  design,  development  .led  implementation 
of  computer  systems  occurs  In  the  maintenance 
phase.  A  significant  reduction  In  the  a»lntenance 
costs  can  be  realized  with  a  design  for  Change 
philosophy  Integrated  Into  the  Engineering  Lift* 
Cycle.  By  carefully  Identifying  the  expected 
changes  to  a  system  and  rigorously  applying  the 
concepts  of  Information  hiding  and  abstraction  of 
Interfaces,  the  changeable  aspects  of  a  system 
can  be  Isolated.  This  paper  provides  an  Ada 
based  design  tutorial,  by  tracing  the  design 
process  and  the  resulting  architecture  based  upon 
these  concepts. 


IntroducUgn 

The  widespread  use  of  computers  over  the  last 
25  years  has  had  pronounced  effects  within  the 
Department  of  Oefense.  It  is  currently  estimvted 
that  the  OoO  spends  about  3  to  4  percent  of  its 
budget,  or  approximately  $10  billion  dollars  per 
year,  on  software.  This  number  Is  expected  to 
Increase  rapidly  In  the  next  few  years  \ 

Unfortunately,  current  methodologies  for 
specifying,  designing,  documenting,  coding,  and 
testing  software  do  not  provide  adequate 
visibility  to  maintenance  concerns.  The 

difficulty  of  generating  software  that  is  easily 
modified  become1-  evident  when  the  full 
Engineering  Life-Cycle  costs  are  examined. 
Figure  1  graphically  portrays  the  distribution  of 
effort  in  the  software  Life-Cycle.  * 


Figure  1.  Distribution  of  Effort  in  the 
Software  Life-Cycle 


Several  facts  are  apparent.  First,  software 
maintenance  costs  more  than  software  development 
activities.  Software  maintenance  Involves  three 
types  of  activity  :  enhancing  the  capability  of 
a  product,  adapting  the  product  to  new  processing 
environments,  and  correcting  bugs. 

Second,  a  large  percentage  of  the  total 
software  effort  Is  devoted  to  software 
enhancements. 

In  recent  years,  several  new  design 
methodologies  and  supporting  languages  have 
emerged  whose  goals  are  to  reducw  the  overall 
costs  associated  with  system  development  by 
reducing  maintenance  costs  and  providing  more 
visibility  to  maintenance  Concerns  during  system 
life-cycle  activities.  -o,  il, Tf 
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1ft  1970.  a  Software  Cost  Reduction  (SCR) 
pro^raa  was  Initiated  by  the  Rival  Research 
Laboratory  that  pursued  these  software 
engineering  project  goals. 

The  SCR  methodology  requires  changes  In  both 
the  design  methodology  and  the  supporting 
documentation  structures.  Key  SCR  concepts  upon 
which  specification  and  design  techniques  are 
based  include  :  u 

1)  Separation  of  Concerns 

2)  Formal  Specification 

3)  Information  Hiding  /  Abstraction  of 
Interfaces 

4)  Documentation  as  a  Software  Design  Medium. 


This  paper  focuses  on  the  role  of  information 
hiding  /  abstraction  of  Interfaces  In  the 
reduction  of  life  cycle  costs. 


Infor»atlon_Hidlng/Abstractionof 

laliLtlSSi 


Information  hiding  I;  a  concept  developed  by 
Parnas  in  1971. 1  When  a  systea  Is  designed  using 
information  hiding  as  a  decomposition  criterion, 
design  begins  with  a  series  of  difficult 
decisions.  Difficult  design  decisions  are 
characterized  by  Impacts  that  affect  sore  than 
one  aodulc.  Each  module  Is  designed  to  hide  such 
a  decision  fro*  the  other  nodules.  Each  module 
in  the  systea  hides  the  internal  details  of  its 
processing  activities,  and  aodules  communicate 
through  well-defined  interfaces.  Unlike 
functional  decomposition,  where  changeable 
aspects  of  the  systea  may  span  several  aodules, 
decomposition  is  structured  so  that  high- 
probability  changes  do  not  affect  the  Interfaces 
of  widely-used  aodules.  Less  probable  changes 
aay  affect  the  Interfaces  of  saall  closely-held 
aodules.  Only  very  unlikely  changes  aay  affect 
the  Interfaces  of  widely-used  aodules. 

Abstraction  is  a  tool  that  allows  one  to  deal 
with  concepts  apart  froa  the  particular  instances 
of  those  concepts.  All  representation  and 
manipulation  details  are  suppressed.  Objects  of 
an  abstract  type  are  known  only  by  the  functions 
that  aay  be  performed  on  then.  Users  of  the 
abstraction  do  not  have  access  to  the  Internal 
details  of  the  abstract  types. 


The  SCR  design  methodology  Is  a  process  In 
which: 

1)  All  expected  changes  are 
Identified  and  prioritized 
early  In  the  design  process. 

2)  Information  hiding  and 
abstraction  of  interfaces  are 
applied  rigorously  during  the 
decoaposition  of  the  systea 
into  software  aodules. 

Identifying  the  expected  changes  is  a 

difficult  process  that  requires  significant 
familiarity  with  the  application.  Once  the 
expected  ehangts  are  agreed  upon,  they  are 
prioritized  based  on  their  likelihood  of 

occurrence.  Although  all  expected  changes  art 
important,  outside  factors  may  prohibit 

application  of  the  entire  list.  Prioritization 
of  the  expected  changes  allows  some  flexibility 
in  this  decision  process.  These  changeable 
aspects  of  the  systea  become  the  secrets  of 

separate  modules,  thus  providing  a  layer  of 
insulation  betwetn  the  changes  and  the  remaining 
software. 


In  1984,  HS5- System's  Inc.  was  awarded  a 
contract  to  provide  computer-based  training  for 
a  large  signal  collection  and  processing  system. 
The  target  system  hid  a  history  of  frequent  and 
significant  upgrades.  The  initial  training 
system  contract  was  awarded  based  on  the  success 
of  a  prototype  that  demonstrated  the  feasibility 
of  enhancing  training  by  means  of  computer-aided 
instruction. 

Following  a  successful  System  Definition 
phase,  the  government  redirected  the  effort  to 
use  the  SCR  methodology.  This  redirection  was 
based  upon  the  reduced  risk  associated  with  the 
existence  of  a  working  prototype  and  the  desire 
to  apply  the  aethodology  in  the  generation  of  a 
new  system.  To  support  initial  efforts,  SCR 
research  materials  were  provided.  Although  these 
documents  were  not  coaplete,  they  provided  an 
adequate  starting  point  from  which  to  explore  the 
methodology.  Subsequently,  the  methodology  was 
enhanced  and  evolved  as  the  Software  Engineering 
Principles  (SEP)  process. 
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Expecttd  changes  are  changes  which  art,  or 
appear  to  be  logical  evolutions  of  the  system. 
Based  on  customer  inputs,  expected  changes  are 
identified  and  prioritized  during  the  System 
Definition  phase  and  presented  for  review  during 
the  System  Requirements  Review.  Following 
customer  approval,  the  expected  changes  are 
included  in  standard  requirements  soecifieations 
and  designers  are  held  accountable  for  an 
architecture  that  supports  these  concerns. 
Architecture  documents  provide  a  mapping  between 
the  expected  changes  and  the  modules  Impacted  by 
their  implementation. 

Ihe  following  list  is  a  subset  of  the 
expected  changes  identified  during  the  System 
Definition  phase  for  the  computer  based  training 
system  : 

-  terminal  interface 

*  underlying  operating  system 

*  networking  environment 

■  target  system  messages  and  displays 

-  student  evaluation  criteria 

*  student  monitoring  formats 

-  authoring  exchange  necessary 
to  create/modify  scenarios 

-  number  and  characteristics  of 
the  systems  being  simulated 

*  specifications  for  key  data  structures 

-  access  policies  for  key  data  structures 

-  run-time  environment 

>  language  implementation 

*  additional  authors,  students 
and  Instructors 

*  additional  classroom  management  tools 


The  expected  change  list  was  generated  by 
reviewing  modifications  made  to  the  target 
systems  during  the  previous  5  years  and  by 
extensive  interviews  with  customer 
representatives.  To  provide  rapid  access  by 
maintenance  personnel  to  areas  of  concern  within 
the  documentation,  the  expected  changes  were 
grouped  in  the  following  way  : 

•  hardware  related 

-  requirement  related 

-  implementation  related 

These  initial  groups  provided  a  starting  point 
for  architecture  efforts. 


Cqg!CUttr-Bistd.-Tri<aing.Archlt»iitUEt 


The  modularization  strategy  described  above 
leads  to  a  hierarchical  structure  in  which  each 
higher-level  module  hides  the  design  decisions 
encompassed  by  Its  descendents.  Based  on  the 
expected  change  list,  a  four  level  architecture 
was  derived.  Ihe  first  two  levels  are  generic  in 
nature  and  would  probably  apply  to  any  system. 
Levels  one  and  two  are  logical  groupings  while 
levels  three  and  four  are  physical  and  correspond 
to  Ada  packages. 

The  first  level  of  the  hierarchy  consists  of 
three  modules: 

-  the  Hardware-Hiding  module 

-  the  Behavior-Hiding  module 

•  the  Softwa;e  Decision-Hiding  module 


Hardware-Hiding  Module 

The  Hardware-Hiding  module  consist  of  modules 
that  need  to  be  modified  if  any  of  the  hardware 
is  replaced  with  a  new  unit  with  a  different 
hardwart/software  interface  but  with  the  same 
general  capabilities. 

The  Hardware-Hiding  module  is  further 
decomposed  into  the  Extended  Computer  and  the 
Oevice  Interface  modules.  The  Extended  Computer 
module  hides  those  characteristics  of  the 
hardware/software  interfile  that  are  likely  to 
change  if  the  computer  is  modified  or  replaced. 
It  implements  virtual  hardware  that  is  used  by 
the  remaining  software.  In  particular,  this 
module  supports  operating  system  related  expected 
changes  by  hiding  the  underlying  operating 
system.  By  specifying  primitives  for  an  operating 
system  in  the  Virtual  Operating  System  module, 
the  remaining  modules  are  insulated  from  changes 
to  the  operating  system.  Primitives  are 
fundamental  assumptions  located  in  the  package 
specification  that  are  very  unlikely  to  change. 

The  Oevice  interface  module  satisfies  the 
network  and  terminal  related  expected  changes 
through  the  Virt'ul  Network  Interface  and  the 
Virtual  Terminal  modules.  The  Virtual  Network 
Interface  module  hides  the  commercial  network 
software  and  how  the  functions  are  made  available 
to  the  system.  Changes  to  the  network  hardware 
and  software  are  insulated  from  the  system 
application  packages  by  identifying  network 
primitives.  Networking  primitives  include  such 
'ervices  as  establishing  a  circuit,  sending  a 
message,  and  receiving  a  message.  If  the 
methodology  for  establishing  a  circuit  or  sending 
a  message  changes,  modules  using  the  service  do 
not  have  to  be  modified. 
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The  Virtual  Terminal  module  Insulates  th« 
jystMi  fro m  changes  to  the  terminal  by  providing 
primitives  for  screen  display  and  keyboard 
drivers.  The  display  output  device  is  Managed  as 
a  set  of  windows,  each  with  characteristics  to 
simulate  portions  of  target  screen  displays.  The 
virtual  interface  provides  the  capability  to 
radically  change  screen  characteristics  without 
affecting  existing  software.  The  Virtual  Terminal 
Interface  hides  the  physical  characteristics  of 
the  display  device,  locations  of  the  devices,  and 
windowing  mechanisms. 

Figure  2.  provides  a  block  diagram  of  the 
Hardware-Hiding  Modules. 


HAAOWAME  HKMNG  MOOOi.ES 


The  Shared  Service  modules  consist  of  software 
that  controls  required  external  behavior  common 
to  two  or  more  modules.  These  modules  hide  the 
characteristics  of  the  shared  behavior  and  the 
algorithms  and  data  structures  necessary  to 
implement  the  shared  behavior.  The  Shared  Service 
modules  support  expected  changes  related  to 
module  initialization,  menu  services,  and  control 
structures  coemwn  to  the  modules.  A  change  in  any 
of  these  areas  is  isolated  to  the  Shared  Service 
modules,  even  though  the  change  may  affect  an 
external  behavior  shared  by  many  application 
modules. 

It  should  be  noted  that  all  required  system 
behavior  is  provided  by  the  Behavior-Hiding 
modules.  During  preliminary  architecture  efforts, 
design  credibility  is  established  by  mapping  the 
required  system  behavior  identified  in  the  System 
Requirements  Specification  to  these  modules.  Any 
requirements  not  mapped  to  a  module  or 
mlstaklngly  mapped  to  a  Hardware-Hiding  or 
Software-Decision  Hiding  module  provide  areas  to 
revisit  the  system  architecture.  Several 
discrepancies  were  noted  in  this  manner. 


Figure  3.  provides  a  block  diagram  of  the 
Behavior-Hiding  modules. 


Figure  2.  Hardware-Hiding  Modules 


Behavior-Hidino  Modules 

The  Behavior-Hiding  modules  are  the  modules 
that  need  to  be  modified  if  there  are  changes  to 
the  required  system  behavior.  Required  system 
behavior  is  documented  in  the  System  Requirements 
Specification. 

The  Behavior-Hiding  module  is  decomposed  into 
two  second  level  modules  :  the  Application  Driver 
module  and  the  Shared  Service  module. 


The  Application  Driver  modules  are  the  sole 
controllers  of  a  set  of  closely  related  outputs. 
Each  module  hides  the  rules  determining  the 
values  of  the  outputs  and  the  data  structures  and 
algorithms  necessary  to  implement  the  outputs. 
Expected  changes  dealt  with  in  the  Application 
Oriver  modules  include  the  authoring  exchange 
necessary  to  create  and  maintain  scenarios,  the 
system  administrator  exchange  necessary  to 
maintain  target  system  databases,  the  system 
administration  classroom  management  policies,  the 
processing  unique  to  specific  target  system 
simulations,  the  student  evaluation  processing 
and  criteria,  and  the  student  monitoring 
processing.  Impacts  to  the  architecture  based  on 
these  changes  are  restricted  to  a  single  module. 


BEHAVIOR  HIDING  MODULES 


Figure  3.  Behavior-Hiding  Modules 
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Software  0«cision*Hld1ng  nodules  ire  the 
nodules  thit  need  to  be  modified  if  there  ire 
chinges  to  designer  generated  decisions.  For 
example,  the  choice  of  i  specific  algorithm  not 
specified  in  the  System  Requirements 
Specificition  is  i  designer  genented  decision. 

The  Softwire  Oecision-Hiding  nodule  is 
decomposed  into  three  second-level  nodules  :  the 
Scenirio  lnterfice  nodule,  the  Oitibise  Utilities 
nodule,  ind  the  System  Cencntion  nodule. 


The  Scenirio  lnterfice  nodule  hides  chinges  to 
the  scenirio  villdition  policies,  the  tnnslition 
process  from  the  external  scenirio  languige 
utilized  by  the  authors  to  the  internal  scenirio 
primitives,  and  the  execution  of  those 
primitives.  All  algorithms  to  parse,  validate, 
translate,  and  execute  the  scenarios  arc  hidden 
in  these  nodules.  These  changes  were  allocated  to 
Software  Decision-Hiding  nodules  because  the 
specific  language  implementation  necessary  to 
support  required  system  behavior  was  designer 
determined. 

The  Database  Utilities  nodule  consists  of 
software  that  needs  to  be  modified  if  changes  are 
nade  to  the  database  managenent  system  or  to  the 
internal  storage,  retrieval  or  maintenance 
policies.  To  insulate  application  modules  from 
the  underlying  database  management  system,  a 
Virtual  Database  Interface  module  is  provided.  It 
provides  the  file  management  primitives  necessary 
to  support  Indexed  sequential  access  data 
retrieval.  Any  changes  to  the  data  access 
policies  -are  limited  to  this  module. 

The  System  Generation  modules  hides  the 
expected  changes  related  to  the  software 
processing  environment  and  the  underlying 
language.  It  hides  the  command  structures 
necessary  to  compile  and  link  the  software, 
values  of  system  generation  parameters  that 
select  different  Implementations  of  a  module,  and 
specialized  test  software. 

The  language  Implementation  module  provides  an 
area  to  discuss  features  unique  to  the  specific 
implementation  chosen.  Originally,  the  goal  was 
to  abstract  out  the  underlying  language 
implementation.  Since  this  was  cost  prohibitive, 
it  provided  an  area  to  discuss  the  language 
specific  decisions  that  might  affect  program 
portability. 

Figure  4.  provides  a  block  diagram  of  the 
Software  Decision-Hiding  modules. 


SOFTWARE  DECISION  HIDING  MOOOLES 


Figure  4.  Software  Decision-Hiding  Modules 


Translation  To  Specification 


Designing  a  software  system  Involves  three 
tasks."  The  first  is  decomposing  the  system  into 
modules  to  support  system  requirements.  This  was 
discussed  in  the  first  part  of  this  paper.  The 
second  is  designing  the  interface  of  each  module. 
The  third  is  producing  a  specification  for  each 
Interface  so  that  (a)  implementors  have  enough 
Information  to  write  the  software  ;  (b)  writers 
of  other  modules  have  enough  Information  to  use 
the  modules  and  (c)  information  that  constrains 
or  discloses  details  of  the  Implementation  is  not 
revealed. 

Following  the  decomposition  theme  employed 
during  the  Architecture  phases,  it  is  important 
to  design  the  interface  of  each  module  so  that  it 
consists  only  of  information  about  a  module  that 
is  not  likely  to  change.  In  that  way,  when 
changes  that  affect  a  module  are  required,  only 
the  implementation  of  that  codule  is  likely  to 
require  a  change.  The  Interface  and  all  other 
modules  that  use  the  interface  are  not  likelv  to 
change. 

Although  the  mapping  between  the  module 
decomposition  and  the  Ada  packages  necessary  to 
support  the  module  decomposition  is 
straightforward,  it  is  not  always  clear  how  to 
translate  required  system  functionality  into 
package  access  functions.  The  most  effective 
approach  is  to  focus  on  the  Hardware-Hiding 
modules.  Since  the  inputs  to  and  the  outputs  from 
these  devices  are  discrete  or  well  known,  access 
functions  are  directly  associated  with  outputs. 
Abstract  interfaces  for  the  Virtual  Operating 
System,  Virtual  Terminal,  and  the  Virtual  Network 
modules  were  generated  in  this  manner. 
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For  example,  the  Virtu*]  Terminal  package 
specification  contains  access  functions  to 
support  basic  terminal  functionality,  i.e., 
scroll,  blink,  highlight,  color,  cursor 
positioning,  etc.  Each  functional  abstraction 
should  not  reveal  characteristics  dependent  on 
the  underlying  terminal  implementation.  It  is 
expected  that  some  of  the  functionality  specified 
in  the  interface  would  not  be  used  by  the 
specific  application,  but  necessary  to  fully 
characterize  an  abstract  terainal  interface. 
These  "unused"  functions  would  have  empty 
implementations. 

Some  Software  Oecision-Hiding  module 
interfaces  were  determined  in  a  similar  manner. 
For  example,  the  Virtual  Database  interface  was 
determined  by  consulting  commercial  database 
technical  references  and  allocating  an  access 
function  for  each  service  required  (  get  record, 
insert  record,  delete  record,  etc.}.  The 
integrity  of  the  underlying  data  abstractions 
were  enforced  by  relying  on  Ada's  private  data 
structure  support. 

The  Behavior-Hiding  module  interfaces  were 
generated  by  looking  at  which  system  level 
functions  were  allocated  to  each  module.  In  some 
cases,  there  was  a  one-to-one  mapping  between 
system  level  functions  and  module  access 
functions.  In  other  cases,  several  system  level 
functions  were  combined  into  one  access  function 
with  the  input  parameters  controlling  the 
required  output. 

Figures  5,  6  and  7  provide  graphical 
representation  of  the  Virtual  Terminal,  Virtual 
Database,  and  the  System  Administration  Data 
specification  packages. 

The  SEP  methodology,  like  any  design  process, 
does  not  provide  a  "cookbook"  methodology  to 
transition  from  specification  to  design.  By 
focusing  on  the  Hardware-Hiding  modules,  with 
discrete  inputs  and  outputs,  and  the  modules 
designers  are  most  familiar  with,  a  good  portion 
of  the  interface  functionality  can  be  specified. 


VIRTUAL  TERMINAL  PACKAGE 


KMMatMTtMACt 

tmcniCMwcu 


n«MHWnuct«N 


«K*OU 

•  MMvm 

•  UTBftAW  oomew—tc* 


Figure  5.  Virtual  Terminal  Package 


VIRTUAL  DATABASE  PACKAGE 


MTAAOdllPOtCV 

(ntenoOMNUt 


BOOCO  MOUf  Ntttl 
14  Ml  AIK*  Of  . 
MMTAAIfTMCKN 


OAfADA9CAMf**CTO* 

•  CMC  Alt 
•MIC* 

•  oct 

•  MBOtt 

et*OAK 


Figure  6.  Virtual  Database  Package 


SYSTEM  ADMINISTRATION  DATA  PACKAGE 
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Figure  7.  System  Administration  Data  Package 
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The  specification  of  an  abstract  interface  should 
have  the  following  properties  ,s  : 

•  it  must  not  disclose  any  of  the  changeable 
aspects  of  nodule 

-  it  nust  present  a  concise  description  of  the 
facilities  available  from  a  nodule  in  terms 
of  effects  that  are  directly  observable  to 
the  user 

•  it  should  be  divided  into  sections  and 
formatted  so  that  a  reader  unfamiliar  with 
the  nodule  is  able  to  find  a  piece  of 
infornation  without  having  to  study  the 
entire  interface  specification 

-  it  should  not  provide  duplication  of 
infornation  which  would  wake  using  and 
naintaing  the  document  acre  difficult 

A  complete  example  of  a  nodule  specification 
satifying  these  requirements  and  the  associated 
guidelines  for  generation  is  found  in  reference 
(14). 


Sugary. 

The  ultimate  goal  of  the  SEP  design 
methodology  is  the  reduction  of  costs  associated 
with  the  production  and  maintenance  of  software 
systems.  By  providing  more  visibility  to 
maintenance  concerns  at  each  phase  of  the  product 
development,  engineers  are  better  able  to  plan 
for  the  expected  system  changes.  It  is  too  early 
to  judge  the  success  of  the  methodology  at  this 
level.  Several  years  of  accurate  life-cycle  cost 
data  are  required  to  support  this  premise. 

However,  there  have  been  some  immediate 
benefits  to  the  methodology.  From  a  design 
perspective,  the  methodology  has  proved  very 
successful  in  reducing  near  term  Engineering 
Life-Cycle  costs.  During  a  recent  upgrade  to  the 
system,  three  significant  target  system 
simulations  were  added.  Since  these  simulations 
were  identified  early  as  expected  changes, 
designers  were  able  to  minimize  the  Impacts  of 
these  changes  on  the  existing  architecture  and 
documentation  structures.  Each  simulation  was 
added  as  a  fourth  level  module  under  the 
Simulation  Activity  module.  Commensurately,  the 
original  system  delivery  dates  have  been 
accelerated  and  cost  reduced  to  refect  this 
reduction  in  effort. 

A  second  update  consisted  of  replacing  the 
existing  8088  based  workstations  with  80286 
based  workstations.  Although  the  new  workstations 
provided  higher  resolution  monitors  and  enhanced 
keyboards,  the  impacts  were  confined  to  the 
Virtual  Terminal  module. 


A  final  update  consisted  of  replacing  the 
existing  removable  storage  media  with  fixed 
internal  storage.  This  was  necessary  due  to  the 
unreliability  of  the  disk  drive.  The  decision  to 
replace  the  faulty  drives  was  made  following  the 
successful  completion  of  the  Software 
Integeration  and  Testing  phase.  Although  the 
impact  to  the  operations  concept  was  significant, 
the  software  modifications  were  confined  to  the 
Control  module  and  the  Data  Specification 
modules. 

In  all  cases,  the  impacts  would  have  been  more 
severe  without  a  design  philosophy  that  required 
engineers  to  plan  for  these  changes. 
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Abstract 

W*<Wnt  a««**  lo  RW  »Wtt>»«t « i*  important  when 
prtxwdag  large  quantities  ef  topographical  t*  Iff. 
rain  data.  WWW  the  standard  Direct  10  and  Se¬ 
quential  10  Ada  package*  permit  acre**  lo  Individ¬ 
ual  Me  elements,  they  do  not  allow  the  user  to  read 
large  block*  of  data  at  a  time  and  proem  individual 
element*. 

This  paper  discusses  a  portable  generic  Ada  pack¬ 
age  which  give*  the  nter  acces*  to  ring W  AW  element*, 
whlW  efficiently  reading/ writing  large  block*  of  data 
to  and  from  memory.  The  concept  of  dote  aktlntc- 
twm  it  u*ed  lo  encaptnlatc  the  formal  of  a  blocked 
Me,  whUe  laformelron  Aiding  i«  used  to  encaptnlatc 
the  algorithmic  implementation  of  the  lopport  pro¬ 
cedure*  and  function*. 

Implementation  and  portability  problem*  encoun¬ 
tered  are  prevented  at  the  condutiou. 


1  Ada  File  User  Requirements 

Terrain  and  topographical  map  data  Me*  can  contain  up  to 
a  million  and  a  half  byte*  for  a  one  degree  square  area.  Us* 
ing  Ihe  standard  Sequential .10  or  Direcl.10  package  proce¬ 
dure*  to  read  three-tbousand  (3,000)  512-byte  record*,  one 
at  a  time,  would  impose  a  file  tranifer  time  penalty  ou  the 
processing  of  the  data.  For  every  file  transfer  request,  the 
system  incurs  disk  seek  and  latency  time  before  transfer¬ 
ring  only  a  single  record.  One  way  to  reduce  the  disk  access 
time  is  to  transfer  more  data  at  a  time,  thereby  reducing 
the  number  of  disk  accesses.  Tbi*  could  be  accomplished 
by  the  programmer  by  declaring  an  array  of  data  elements, 
instantiating  an  input-output  package  with  the  data  array, 
and  controlling  reads  and  writes  to  the  external  file  when 
the  data  array  is  empty  or  full.  This  is  contrary  to  tiie 
concepts  of  data  skilrselfen  and  information  hiding,  where 
the  user  should  only  be  coucerned  with  opening,  reading, 
and  writing  individual  records,  and  closing  Die  external  file. 
The  actual  implementation  should  be  hiddeu  from  the  user. 

The  map  data  files  are  usually  written  by  one  computer 
system  and  read  on  another.  It  was  necessary,  then,  to 
define  an  implementation  which  could  be  used  ou  at  least 


three  different  computers  with  three  different  operating  sys¬ 
tems,  using  three  different  Ada  compilers.  That  is,  the  im¬ 
plementation  had  to  be  portabk. 

Map  data  file  have  many  format*  and  contain  various 
number  of  records.  Writing  a  package  to  handle  the  block¬ 
ing  and  deblocking  operations  for  each  data  format  would 
not  only  be  time-consuming,  but  a  duplication  of  effort. 
It  would  be  better  to  write  the  operation*  once,  encapsu¬ 
late  them  in  a  package,  and  parameterise  the  package  with 
the  data  record  formal  and  the  number  of  records  per  data 
Mock. 

The  above  description  of  (be  proMetu  Wad*  us  to  define 
the  user  requirements  as: 

•  Reduction  of  disk  access  time 

•  Encapsulation  of  operations  in  a  package 

•  Hidden  Mocked  data  structure 

•  Portable  package 

•  Generic  package 

The  following  sections  disenss  the  design  of  the  generic 
parameters,  the  package  user  interface,  and  tbc  implemen¬ 
tation  of  tbe  package. 

2  User  Interface 

2.1  Deaign  Consideration 

The  input.output  facilities  of  Ada  [LRM  83]  are  capable 
of  handling  sequential  files  by  means  of  the  SequcntialJO 
package,  or  random-access  files  by  means  of  the  Direct  JO 
package.  It  is  not  possible,  ltowever  to  specify  that  files  be 
transferred  as  blocks  of  records.  Tbe  only  way  to  provide 
this  capability  is  by  means  of  a  user-developed  package. 
For  sake  of  consistency,  the  package  should  conform  to  the 
structure  of  the  existing  input-output  packages. 

For  example,  the  Sequential.IO  and  Direct.IO  packages 
are  implemented  iu  similar  manner.  When  only  sequential 
access  is  required,  the  procedures  in  Direct  JO  can  be  used 
iu  exactly  the  same  way  as  those  procedures  in  Sequeu- 
tialJO.  Tliis  concept  of  similarity  was  used  in  the  imple¬ 
mentation  of  the  new  BlockedJO  package.  This  similarity 
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supports  the  Software  Engineering  goal  of  Undcrttaudabil- 
Hy.  Tbe  more  alike  the  procedure*  in  tbe  Blocked  10  pack- 
•i*  wt  It)  those  in  0*  Direct ,10  package,  Ike  moce  ike 
»#er  will  ke  able  to  understand  Ikeir  functionality  and  u#e 
them. 

Tke  Mocked  file  organisation  allow*  tkc  t»*er  lo  read 
and  wrile  individual  logical  record*  without  regard  io  Ikeir 
position  wilkin  Ike  physical  Mock  I  key  are  in.  Tke  Mocked 
file  ylrnctnre  i*  Iku*  determined  by  only  two  kind*  of  infer* 
malion:  Ike  kind  of  dala  element,  and  Ike  1  docking  factor. 

Translated  into  Ada  notation,  only  two  generic  actual 
parameter*  mn«t  ke  fupplied  fcr  any  particular  instantia- 
tion  of  ike  Blocked .10  package:  tke  ELENENT.TTFE  cud  tke 
BLOCXIM  FACTOR.  Tke  user  ka*  complete  freedom  to  »pe<* 
ify  any  dala  record,  including  variant  record*.  Tke  generic 
formal  part  of  tke  Bfeckrd.lO  package  i*  written  a*  *kown 
in  below 


gaaarle 

typa  ELENENT.TTFE  i«  privata; 

—  Logical  Record  Typa 

ILOCRINC.FACTOR  :  i*  POSITIVE; 

—  Noabor  •(  Logical  Racoria  par  Hack 


2.2  Package  Specification 

Since  similarity  witk  tke  Direct  .10  package  waa  desired, 
tke  apeeification  part  of  tke  BloekedJO  package  i«  kuilt  in 
tke  same  way  aa  Ike  apecificatiou  part  of  Direct  10.  Tke 
Blockcd.10  package  export*: 

a  type* 

•  exception* 

•  file  management  operation* 

•  inpul-output  operation* 

There  are  a  few  batic  difference*  between  tke  package*. 
The  Blocked  10  package  ditallow*  tke  uir  of  the  NODE  pa> 
raweter  since  all  operation*  are  baaed  on  direct  acre**. 

The  following  acctiona  diacut*  tlioae  item*  which  differ 
from  the  specification*  of  Direct  10.  A  complete  lilting  of 
tke  specification  part  for  BloekedJO  is  given  at  the  coudu* 
tion  of  this  article. 

Type* 

The  FILE..TYPE  specified  for  the  Blocked.  10  package  is  the 
same,  but  the  FILE. NODE  i*  omitted,  siuce  all  operation* 
are  baaed  on  direct  access.  The  mode  it  always  set  to 
INOUTJrILE.  The  integer  type*  COUNT  and  POSITIVE.COUNT 
used  for  file  indices,  are  specified  as  iu  Direct  JO. 


Exceptions 

All  the  exception*  of  Direct  JO  are  available  except  for 
NODE.EMON,  which  i*  omitted  since  th«  u*er  i*  not  permit, 
ted  to  xpecify  the  mode  in  either  a  CREATE  or  OPEN  opera¬ 
tion. 

Pile  Management  Operation* 

Tke  CREATE  and  OPEN  file  management  operation*  do  not 
require  the  PORN  parameter,  likewise,  tke  NODE  function 
I*  omitted.  Tke  remaining  file  management  operation*  * 
CLOSE,  DELETE,  RESET,  SANE,  PORN,  SIZE  and  IS.DPEN 
•  are  exactly  the  same  a*  those  defined  for  Direct  JO. 

There  arc  three  kind*  of  record*  manipulated  hy  tke 
package: 

•  logical  record* 

•  external  .record* 

•  internal. record* 

Tke  utcr  reads  and  write*  a  logical  record  using  tke 
Blocked  10  operation*.  This  is  also  tke  record  type  that 
I*  used  to  Instantiate  the  BloekedJO  package.  Kecocdt  of 
this  type  arc  number  from  one  lo  tkc  last  record  written  by 
the  user. 

An  oxtoraaljrocord  is  transferred  to  and  from  the 
external  file.  It  consist*  of  RLOCFINQ .FACTOR  number  of 
leglcal^ocorda.  These  records  arc  numbered  from  one 
to  the  last  "block”  written  by  the  BloekedJO  Writ*  proce¬ 
dure.  The  number  of  the  last  axtaraal^acard  is  returned 
by  ike  Six#  function. 

An  iat*raal.r*card  is  one  of  tke  logical. records 
contained  in  the  internal  SUFFER,  which  ka*  been  read  in 
from  an  oxtoraal  .record.  Tkc  iatormaljrocord  number 
range*  from  one  to  BLOCEINC .FACTOR. 

Three  additional  file  management  function*  have  been 
defined  for  the  BloekedJO  package  to  help  tke  user  identify 
which  logical,  internal,  or  external  record  is  being  manipu¬ 
lated,  These  function*  replace  the  Iadox  function  available 
in  the  Direct  10  package.  These  function*  arc  named  for 
tbe  record  type*  manipulated: 

•  Logical  Record* 

•  External. Record* 

•  Internal. Record* 

These  function*  return  the  number  of  l  he  externa;  file  record 
currently  in  memory,  the  number  of  the  logical  record  in  tbe 
file,  and  the  number  of  the  logical  record  in  the  external 
record,  re*pectively. 

Input-Output  Operation* 

The  input-oi-‘put  operation*  of  the  BloekedJO  package  are 
identical  to  tho«e  of  the  Direct  JO  package.  There  it  no 
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tut  lafax  procedure,  however,  m  tbi*  capability  i«  fur¬ 
nished  by  tbe  Kn4  and  Writ*  procure*  when  u*ing  (be 
FRO*  and  TO  parameter*. 

2.3  Example  of  Usage 

To  »Uo*traie  ib«  u*e  of  tbe  Biocked.lO  package,  we  will 
write  a  Me  of  2-W-byU  record*,  blocked  by  fewr,  mulling 
in  an  external  file  record  wbo*<  site  I*  102-t-byte*.  Tbe 
record*  will  be  written  sequentially. 

oitk  SLOCKED. 10; 

pncWu*  test.driver  i$ 

typo  DATA. RECORD  i*  array  (1..04)  of  FLO  XT; 

—  M  ilNMti  x  4-bytat/alaaaaat  «  2S4  bytaa 

package  TUT.  10  ia 
•a*  RL0CEE0.X0 

(HDtnrr.rrn  »  data .record, 

ILOCRIBO.FACTOR  •>  4); 

—  Tbi*  ia  tba  iaateatiatioa  of  tka  ILOCKED.XC 

—  package  aitk  tka  2M-byta  DtTt.UCOU,  ant 

—  a  BLOCK IRQ. FACTOR  ai  4,  giving  an  axtarnaX 
--  file  record  aima  of  1024-byte*. 

Taat.rila  :  TEST.IO.FILE.TTFE; 

—  Tkia  ia  tka  iateraal  file  Mkaa41eM 
--  far  tka  axtarnaX  fiXa. 

Teat. Data  i  DATA. RECORD; 

—  TMa  ia  tka  214-byte  taat  fata  recorf. 

Vagin  —  TUT. DRIVER 

—  Xnitialixe  tka  taat  fata  array  ta 
•—  toqaoatiel  fXaating-paint  vaXaaa. 

INITIALIZE: 

far  I  in  1..44  Xaap 

Taat. Data  :«  FLOAT(I) ; 
anf  Xaop  INITIALIZE; 

--  Nob,  create  (anf  open)  a  fila 
--  to  contain  tka  taat  fata 


--  Since  tka  Vleckiag  factor  ia  4, 

--  only  ((10  /  4)  ♦  1)  axtarnaX 
--  racarfa  of  1024  Vytaa  akealf 

—  Ve  arittaa. 

WRITE. DATA. RECORDS: 
far  I  in  1..10  leap 

Tt$T.10.VMTX(FILE  ■>  Taat. Fila, 

ITEM  ->  Taat. Data); 
anf  Xaap  WRITt. DATA. RECORDS; 

—  Nob,  daaa  tka  axtarnaX  file. 
TZST_X0.CL0SE(FILE  •>  Taat. Fila); 

aaf  TEST. DRIVER; 

Note  how  the  tent  program  aiinply  indicate*  that  ten 
data  record*  are  la  be  wrillen  la  the  Hie.  Blockin';  af  the 
data  record*  i«  automatically  performed  by  tbe  instantiated 
package,  relieving  the  user  program  fram  having  la  perform 
three  operation*. 

Aina,  »inrc  the  latl  external  file  recocd  contained  only 
Iwa  logical  record*,  the  remainder  of  Ibe  record  wn«  aulo- 
malically  tel  la  xeroa  when  Ike  internal  buffer  waa  creeled. 

3  Implementation 

3.1  The  Underlying  Data  Structure 

The  implemcnlalian  of  Ibe  Mocked.lO  package  it  bated 
on  ntage  of  tlandard  Ada  elemenlt.  Tbe  retaurcet  of  Ibe 
Direct  10  package  are  uted  la  implement  all  of  Ibe  input- 
output  operation*.  The  data  tlruclurc  uted  la  implement 
tbe  blocked  file  can  therefore  be  mapped  directly  to  tbe 
underlying  direct  file  record*. 

Tbe  blacked  file  it  an  array  of  ELEMENT »TTFE  record*. 
Tbe  blocked  type,  NOFTER .RECORDS,  it  declared  iu  the  pack¬ 
age  private  tectiont,  along  with  the  RECORD. XNDEX.TYFE  ar¬ 
ray  index  type.  The  operation*  of  Direct  10  are  imtan- 
tiated  in  the  private  part  of  the  package  ipecilication  a* 
the  BIO  package  with  the  BUFFER  .RECORDS  type,  aud  the 
Blocked, 10  package  FXLE.TYFE  i«  defined  a*  a  record  with 
it*  tingle  component  Data  Fila  as  the  instantiated  package 
file.tyire,  a*  shown  in  below 

privat*  --  Blockad.IO  packag* 


TEST. 10. CREATE (FILE  ->  Tott.Fila, 

UAH*  mm v  ItVffCV  IS  14*11  \  . 


'•  subtyp*  RECORD. INDEX.TYPE  it 

NATURAL  rang#  1. .BLOCKING. FACTOR; 

-  Writ,  tax  2S«-byt.  racorf*.  „  lBt.„#1  r#cord  iBd„ 

--  Va  Bill  aiwply  »rit#  tka  ia«a 

—  racorf  tax  tioes. 
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in*  wrm.ucouM  i* 

utijr  (mcoM.irotx.rrn)  •<  elekevt.tyfe; 

--  htMMl  im«4  data  xjj 

packags  BIO  is 

IM  DIRECT. XO 

(elemert.ttfe  •>  »crm.  records)  ; 

—  lutUtUllM  •<  DXRECT.IO  (UK  blocksd  tKOtit 

tyya  FILE.TTPE  is  m*r4 
Data.Fils  :  RXO.FXLE.TTPE; 
m4  r*<«4; 

—  buml  tils  "haadls" 


3.2  Implementation  Design 

Implementation  of  Ike  Bhxked.lO  package  requires  an  in¬ 
ternal  "blocked"  *'uffer,  ihtee  pointer*,  and  a  Bsc  variable. 
Thus,  Ike  paring-;  function*  m  a  stale  machine,  since  it 
must  relain  knowledge  of  its  previous  stale  from  call  to 
call.  These  "slate'1  variable*  are  shown  below 


Bstfsr  :  IOFFER. RECORDS; 

—  Internal  bsfftr 

Carr sat. Block. Raabsr  :  COURT  :■  0; 

--  Rssidoat  block  naakar 

Carroat.Rocord.Rsabor  :  COURT  :■  0; 

--  Logical  record  nnakar 

Bat t er. Record. Rusher  :  RECORD.IBDEX.TYFE; 

—  Physical  record  number 

Ctrreat.Block. Modified  :  BOO LEAR  FALSE; 

--  "Dirty**  block  flag 

The  Current. Block. Rumber  mainlnius  (he  number  of 
the  external  file  record  ("block").  It  it  initialised  to  xero, 
indicating  that  no  external  file  record  has  been  read  into 
memory.  The  Current  Record  .Rumber  maintains  the  log¬ 
ical  record  number,  regardless  of  which  external  ("block") 
file  record  it  is  iu.  It  is  also  initialised  to  scro,  indicating  no 
logical  record.  The  Buffer^ecordJI umber  maintains  the 
number  of  the  logical  record  within  the  current  buffer.  Fi¬ 
lially,  the  Current  JlockJtodif  led  flag  indicates  whether 
auy  of  the  record*  contained  within  the  current  block  have 
been  mollified.  If  so,  the  current  block  must  be  written 
to  the  external  disk  file  before  any  other  record  not  iu  the 
current  block  is  read  or  written. 

In  addiiiou  to  the  functions  and  procedures  identified  in 
the  Blocked  10  package  specification,  two  additional  func¬ 
tions  were  writteu  in  the  package  body  to  support  the  de¬ 
termination  of  the  correct  external  record  number  and  the 


internal  record  number.  The  Is,  I  luck  function  take*  the 
logical  record  number  and  returns  the  external  fik  record 
nnmber.  The  Is -Recur  4  function  take*  the  logical  record 
number  nnd  returns  the  number  of  the  record  in  the  ex¬ 
ternal  record  bo  He*  Thus,  by  using  these  two  function#, 
wt  can  determine  which  external  file  record  to  read  in  from 
disk,  and  whirh  record  to  acres#  from  the  Internal  buffer  to 
obtain  the  specified  logical  record. 

Calculating  the  External  Pile  Record  Number 

Calculation  of  the  number  of  the  external  file  record  which 
contains  the  specified  logical  record  is  performed  using  in¬ 
teger  arithmetic.  The  logical  record  number  Is  divided  by 
the  blocking  factor,  and  one  added  to  the  result.  If  the 
logical  record  is  a  multiple  of  the  blocking  factor,  then  the 
external  file  record  number  is  reduced  by  one. 

Calculating  tb«  Internal  Buffer  Record  Number 

Calculation  of  the  number  of  the  record  within  the  internal 
buffer  is  also  performed  using  integer  arithmetic.  The  result 
Is  computed  as  the  logical  record  number  nod  the  blocking 
factor.  If  the  result  is  xero,  then  the  internal  record  number 
is  set  to  the  blocking  factor  (the  last  record  in  the  internal 
buffer). 

Reading  Records 

The  Road  procedure  determine*  the  correct  external  file 
record  numlter  and  internal  record  numbers,  then  reads  the 
external  record  from  disk  into  the  buffer  contained  in  the 
package  body.  Before  reading  in  the  next  buffer,  however, 
the  procedure  first  tbeck#  to  see  if  the  current  buffer  bas 
been  modified.  If  it  ha*  been  modified  (that  is,  the  "dirty" 
Hag  is  set),  then  it  writes  out  the  current  buffer  by  calling 
the  Flush  procedure. 

The  Rsad  procedure  i*  overloaded  to  allow  the  user  to 
read  records  randomly  or  sequentially.  If  the  record  number 
is  not  specified,  the  next  logical  record  is  read  and  returned 
to  the  user.  The  sequential  read  pnxedure  adds  one  to 
the  current  logical  record  number,  and  call*  the  overloaded 
direct  read  procedure. 

Writing  Records 

T!»c  Vrits  procedure  is  also  overloaded  to  permit  the  user 
to  write  records  randomly  or  sequentially.  If  the  number  of 
the  record  to  read  is  not  specified,  tire  logical  record  number 
is  incremented  and  used  to  call  the  overloaded  direct  write 
procedure. 

The  direct  Urito  procedure  determines  the  correct  ex¬ 
ternal  record  and  internal  record  numbers,  then  writes  the 
record  to  the  correct  position  within  (he  internal  buffer. 
If  the  external  record  to  write  is  not  the  one  currently  in 
memory,  then  the  current  block  buffer  is  written  out,  a  new 
buffer  is  initialised,  and  the  new  record  writteu  to  the  new 
current  buffer. 
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Buffer  lnHItliutwn 

Before  writing  any  record  to  a  new  block  (that  is,  *  block 
which  will  Ik  written  after  the  dm!  vl  *!«-  current  Ilk  rise), 

•  m«  block  buffer  i<  initialised  to  null*  {w«|.  Since  (Ik 
record  I*  fttroM  ai  instantiation  time,  St  5*  not  poaribk  to 
write  null  record*  to  the  buffer  unics*  we  required  the  u#er 
to  furuirit  i*  null  record.  W't  chose  not  to  do  tbi*.  Instead, 
we  averUy  it  itull  buffer  ©«  top  of  the  intent*!  buffer,  a* 
shown  In  tbe  following  code: 

XMTXAUIE:  declare 

—  First,  flad  out  hoe  May  hytee  in  the  VIkM 

—  buffer  ky  obtaining  the  amber  of  kita  ia  the 
--  buffer  type  and  dividing  ky  the  amber  of  kite 
--  ia  tka  StSTtM.ITOMCC  unit. 

Seffer.Siae  :  constant  POSITIVE  :• 
(iorra_wcow>i’»i*«  / 

STSTDt.StOIU6C.VIXt); 

--  Sait,  craata  aa  array  aitk  tka  uaa  amber  al 

—  STSTDI.ST0IU6C  unit.,  filled  aill  aalXa. 

Null. Suffer  :  array (1. . luffar.Siaa) 
of  ctuiucm  :* 

(ethers  ->  ASCII. 1.1); 

--  I**,  equivalence  tkia  aall  array 
--  aitk  tka  input  klacka4  buffer. 

far  Null.Suffer  aaa  at  luffer'addreae; 

begin  "  INITIALIZE 

—  All  operation*  performed  ia  4aclara  xuntemote 

aall; 

aa4  INITIALIZE; 

Initialiiatiou  of  tbe  interunl  buffer  eould  have  been  ac¬ 
complished  by  usiug  VNCNECEED.CONVEMION  to  convert  tbe 
WLLJOrm  to  a  NVPFDUIECOkDS  type,  and  copying  it 
to  tbe  internal  buffer.  W'e  decided  not  to  implement  tbii 
method,  a<  it  would  require  additional  memory  for  the  null 
buffer. 

4  Portability  Issues 

To  achieve  the  goal  of  portability,  oidy  procedure,  and  op¬ 
eration.  available  in  Ada  were  uted  to  implement  the  pack¬ 
age.  That  it,  no  DEC  VAX  .y.teui  service  call,  were  made 
in  any  of  the  procedure*  or  function.. 


One  difficulty  encountered  in  tbe  creation  of  the  package 
wu#  tbe  implementation  of  the  Para  function.  Thi»  function 
return*  a  string  which  contain*  tbe  form  information  u*ed 
to  open  oc  create  tbe  file. 

One  way  to  implement  tbi*  function  would  be  to  return 
tbe  form  tiring  obtained  from  a  call  to  tbe  underlying  Di¬ 
rect  10  Pom  function,  a*  tbown  in  the  following  function: 

function  POMfPIU  *  ia  PXLt.TTPE) 

rotara  ST1UN6  ia 
kogia 

rotara  110. POMfPIU  •>  FIU.Dota.Pilo); 
o«4  POM; 

Unfortunately,  tbl*  did  not  work  on  tbe  DEO  VAX. 
DEC  implement*  tbe  form  tiring  uting  their  proprietary 
Kik  De*cri ption  Language  (FDL).  Tbe  itring  returned  ex¬ 
ceeded  tbe  constraint  for  tbe  return  STMSO  type.  Afte* 
a  few  call*  to  DEC  Customer  Support,  the  probkm  wat 
resolved,  and  the  function  implemented  a*  follow*: 

faactioa  POMfPIU  :  ia  PXU.TTPE) 
rotara  STNINC  ia 

Fera.Striag  :  constant  STX1N6  :■ 

■10. POMfPIU  ->  FIU.Dota.Pilo) ; 

kogia 

rotara  Pora.Striag; 
oa4  POM; 

Tbi*  implementation  permit*  tbe  unusually  long  form 
*tring  returned  by  tbe  underlying  Direct  10  Pom  fonclion 
to  be  atrigned  to  a  constant  string  each  time  tbe  Blocked  .10 
Pom  function  is  calkd.  Then,  this  constant  string  it  re¬ 
turned  to  the  caller. 

5  Performance  and  Tuning 

Performance  of  tbe  Blocked  10  package  depend*  upon  tbe 
rise  of  tbe  logical  data  record  and  the  blocking  factor.  Tbe 
smaller  tbe  rise  of  tbe  data  record  and  the  smaller  the  block¬ 
ing  factor,  the  larger  the  disk  access  time.  By  blocking 
the  data,  more  data  can  be  written  at  a  lime,  and  fewer 
disk  acce.se*  are  required.  While  larger  external  file  record 
rises  (data  blocks)  will  result  in  fewer  disk  access  to  trans¬ 
fer  data,  they  will  require  more  memory  rise  to  retain  tbe 
internal  buffer.  Choice  of  the  blocking  factor  is,  then,  a 
trade-off  between  how  much  memory  is  available  and  the 
desired  data  transfer  rate. 

Two  benchmark  programs  were  written  to  obtain  the 
time  required  to  write  fifty-thousand  (50,000)  two-hundred 
fifty-six  (250)  byte  records  to  disk.  The  first  program  called 
the  Direct.lO  Writ*  procedure  to  sequentially  write  the 
records.  The  second  program  called  the  BlockedJO  Writ* 
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procedure  to  write  the  record*  tegucutially.  It  wm  esti¬ 
mated  that  the  Blotked.lO  package,  inatantialed  vilh  the 
2.MS-byte  record  and  it  StOCXIK -FACTO*  of  ten  (10)  *«wH 
execute  quicker  than  the  corresponding  operation*  It\  the 
Direct  10  package. 

In  fuel,  the  oppoaitc  wm  found  to  he  true,  m  ahown  in 
in  the  following  table: 


Direct. IC  llock*4.I0 
tlayi*4  Tin*  2:07. St  2:21.47 


CTO  Tin* 
(niUi»*coa4i) 

•u«*r*4  10 
(*p«ratioai) 

Direct  10 
(*f*r«ti«in) 


14070  27210 

•H  «M 

34M  24*3 


Suapecling  a  Haw  in  the  procedures  we  ran  the  program 
with  the  DKC  VAX  Symbolic  Debugger.  Unable  to  detect 
any  obviou*  error,  we  wrote  a  third  tc*l  program.  Thi* 
time,  w«  declared  Blocked  10  m  an  interna],  non-generic 
package  inridc  the  teat  program.  When  we  ran  thi*  pro¬ 


gram  with  the  aame  teal  data,  we  found  that  tbt  CPU 
execution  time  wm  123*0  milliaeeond*.  Thi*  rtpre#ented  a 
twelve- percent  reduction  in  the  Direct.10  execution  time, 
and  a  fifty-two  percent  reduction  in  the  execution  time  of 
the  Bfocked.lO  procedure. 

Since  the  only  obvkw*  difference  in  the  but  leal  program 
wm  the  lack  of  generic  instantiation  of  the  package,  we 
have  Maumed  that  aomething  in  the  implementation  of  the 
inatantlatfon  of  a  genetic  package  Sa  affecting  the  execution 
time*. 

Thia  Maumptkm  it  auppoc ltd  by  the  independent  article 
of  [If  err  IMS }  which  indicate*  "the  inability  of  many  validated 
Ada  compiler!  to  properly  handle  generic  unit*.* 

6  Conclusion* 

The  Bfo'ked  10  package  ia  an  example  of  how  Ada  can  be 
extended  by  meana  of  package*.  With  care,  the  uaer  goola  of 
portability  and  rentability  can  he  met  while  auppoding  the 
Software  Engineering  goal  of  undcratandability.  The  uaer 
goal  of  apeed,  however,  aometime*  elude*  even  the  tar  nett 
programmer. 

Until  Ada  compiler*  correctly  and  efficiently  implement 
generic  package*  programmer*  are  denied  the  primary  fa¬ 
cility  which  promote*  the  creation  of  rentable  software. 
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7  Blocked  JO  Package  Specification 


—  BLOCKED. 10  PACKAGE  SPECIFICATION 

rMMKi  IO.EXCEPTIONS.U5E.ERROR; 

--  File  capacity  exceeded,  non-existent  ill*, 

--  *lr eady  existing  file,  or  improper  FORK  string 

—  specified  daring  CREATE  or  OPEN. 

DEVICE. ERROR  s  exception 

renames  XO. EXCEPTIONS. DEVICE. ERROR; 

—  Underlying  Rnrd*t<r«  malfunction. 

END. ERROR  :  exception 

renames  IO.EXCEPTIONS.END.ERROR; 

--  Attempt  to  reed  record  after  last 
--  block  in  external  file. 

DATA. ERROR  :  exception 

rename*  10. EXCEPTIONS. DATA. ERROR; 

--  Unable  to  read  Blocked  Buffer. 

--  Possibly  wrong  blocking  factor. 


—  BLOCKED. 10  PACKAGE  PRIVATE  SECTION 


private 

subtype  RECORD. INDEX. TYPE  i* 

NATURAL  range  1. .BLOCKING.FACTOR; 

type  BUFFER.RECORDS  i* 

array (RECORD.INDEX.TYPE)  of  ELENENT.TYPE; 

package  BIO  is 

nev  DIRECT. 10 (ELENENT.TYPE  «>  BUFFER.RECORDS) ; 

type  FILE.TYPE  is  record 
data. file  :  BIO. FILE.TYPE; 

ITEH  :  out  ELENENT.TYPE; 

FRON  :  in  FOSITIVE.COUNT); 

—  Returns  the  element  "ITEN"  from  the  logical  record 

—  number  "FRON".  Raises  END.ERROR  exception  if  "FROM" 
--  causes  read  beyond  SIZE(FXLE). 
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procedure  HUD  (FILE  i  in  oat  FILE.iTPE; 

ITER  :  put  ELERERT.TTPE); 

—  Returns  the  element  "ITER"  from  the  current  logical 

--  r«cor4  number  then  increment*  the  logical  record  number. 

-■  Raises  END. ERROR  exception  if  currant  record  number 
--  causes  read  beyond  SIZE(FILE). 

procedure  VRITE(F1LE  :  in  out  FILE.TTPE; 

ITER  t  in  ELERERT.TTPE; 

TO  :  in  POSXTIVE.COURT); 

—  Vritag  "XTERH  to  tka  logical  racord  number  "TO". 

procadnra  VRITE(FILE  :  in  ont  FILE.TTPE; 

ITER  :  in  ELERERT.TTPE); 

—  Increments  tka  entrant  logical  racord  nniakar, 

—  tkan  writes  "ITER"  to  tka  -FILE". 

—  Exceptions 

STATUS. ERROR  :  axcaption 

rename*  10. EXCEPTIONS. STATUS.ERROR; 

--  Attempt  to  oparata  on  nnopanad  fila, 

—  or  opan  an  already  opanad  fila. 

RARE. ERROR  :  axcaption 

raROiaai  10.  EXCEPTIONS.  RARE.  ERROR; 

--  Invalid  "RARE"  string  apacifiad  during 

—  CRUTE  or  OPEN. 

USE. ERROR  :  axcaption 

function  FORR  (FILE  ;  in  FILE.TTPE)  raturn  STRIRC; 

--  Raturns  tka  form  usad  to  opan  or  craata  tka  axtarnal  fils. 

proesduts  PRIRT.FORR  (FILE  :  in  FILE.TTPE); 

--  Prints  tka  form  string  associatsd  uitk  tka  axtarnal  fila. 

function  Physical.Record(FILE  :  in  FILE.TTPE) 
raturn  P0SITIVE.C0URT; 

--  Raturns  tka  currant  (physical)  Blocked  Buffar  racord  numkar. 

function  Logical. Racord(FILE  :  in  FILE.TTPE) 
raturn  P0SITIVE.C0URT; 

—  Raturns  tka  currant  (logical)  racord  numkar. 

function  Rasidant.Racord(FILE  :  in  FILE.TTPE) 
raturn  P0SITIVE.C0URT; 

—  Raturns  tha  currant  logical  racord  numkar 

—  (in  tha  currant  physical  racord) 

function  SIZE  (FILE  :  in  FILE.TTPE)  raturn  COURT; 

—  Raturns  tha  numkar  of  tha  last  physical  record 

—  in  tha  axtarnal  fila. 

function  IS.OPER  (FILE  :  in  FILE.TTPE)  raturn  BOOLEAN; 

—  Raturns  TRUE  if  "FILE"  is  associatsd  with  an  axtarnal  fila. 
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function  END»OF..rXLEtFXLE  s  in  FILE.TTPE)  return  BOOLE**; 

—  Returns  TRUE  if  "FILE"  is  at  th*  last  physical  record 

-  in  th*  external  fil*. 


--  Input  and  output  operation* 


procedure  REID  (FILE  :  in  out  FXLE.TTPE; 

procedure  0PEN(FILE  :  in  out  FXLE.TTPE; 

RARE  :  in  STRING 

FORK  :  in  STRING  ;»  *“>; 

—  Associate*  tK«  fil*  object  "FILE"  with  the 

—  external  fil*  specified  by  tho  .\«um  ’‘HA ME". 

procedure  CLOSE(FXLE  :  in  out  FILE.TTPE) j 

—  Diuconnoctu  th*  current  association  of  th* 

■ -  fil*  obj«ct  "FILE"  with  ita  *xt*rnal  fil*. 

proc*dur*  DELETE(FXLE  :  in  out  FXLE.TTPE); 

--  Disconnects  tb*  current  association  of  tb* 

—  file  object  "FILE"  with  it*  *xt*rnal  fil*. 

—  Tb*  *xt*rnal  fil*  c*aa*a  to  *xi*t. 

proc*dur*  RESET(FXLE  :  -in  out  FILE.TTPE) ; 

—  Rewind*  th*  fil*  object  ***oci*t*d  with  "FILE". 

--  Sat*  th*  Bloch  and  Record  numbers  to  on*. 

procedure  FLUSHCFILE  :  in  out  FILE.TTPE); 

--  Fore**  th*  currant  Blocked  Buffer  to  b* 

--  written  to  th*  fil*  object  aa«ociat*d  with  "FILE". 


--  Fil*  information  operation* 

function  NAME  (FILE  :  in  FILE.TTPE)  return  STRING; 
--  Return*  th*  name  which  was  used  to  open  or 

—  create  th*  external  fil*. 

—  BLOCKED.IO  PACNACE  SPECIFICATION 

—  Author:  John  J.  Cupak  Jr.,  CCP 
--  With  Support  From  :  Roy  Hoffman 
--  Dat*  :  24  July  1987 
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Kith  DIRECT. 10 j 
Kith  I0.EXCEPTZ0NS; 

ganarlc 

typa  ELEHENT.TYPE  ia  prlvata; 

—  Logical  racord  typa 

BLOCKING. FACTOR  :  in  POSITIVE; 

--  Nuabar  of  logical  racorda  par  block 

packaga  BLOCXED.IO  it 

typa  FILE.TYPE  ia  limltad  privata; 

typa  COUNT  it  ranga  0. .INTECER'LAST 

aubtypa  P0S1TIVE.C0UNT  ia  COUNT  ranga  i..COUNT*LAST; 

procadura  CREATE(FILE  :  in  oat  FILE.TYPE; 

NAHE  :  in  STRING  :■ 

FORK  :  in  STRING  . . . 

--  Craataa  an  axtarnal  fila  Kith  tha  naaa  “NAHE" 

—  and  aaaociataa  tha  fila  objaet  “FILE"  Kith  it. 

typa  BUFFER.RECORDS  la 

array (RECORD.INDEX.TYPE)  of  ELEHENT.TYPE; 

packaga  BIO  ia 

naa  DIRECT.IOCELEHENT.TYPE  ■>  BUFFER.RECORDS); 

typa  FILE.TYPE  ia  racord 
data. fila  :  BIO. FILE.TYPE; 
and  racord; 

and  BLOCK EO.IO; 
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a  senior  programmer,  Mr.  Cupak  generated  and 
maintained  UNlVAC-llOO  system  software.  He 
implemented  a  computer  Job  sustsary  aceaunc 
program  In  structured  COBOL  to  support 
corporate  billing  system.  He  designed  Oata- 
graphlcs  4500  Computer  Output  Microfilm  (COM) 
control  and  formatted  programs.  He  designed 
and  Implemented  the  first  on-line  documentation 
manual  and  help  commands  for  proprietary  data 
retrieval  language. 

Mr.  Cupak  was  a  graduate  teaching 
assistant  in  the  Department  of  Computer 
Science  at  the  State  University  of  Kev  York  at 
Albany.  Mr.  Cupak  was  responsible  for  devel¬ 
oping  and  teaching  structured  programming  in 
COBOL.  Mr.  Cupak's  thesis,  "Application  of 
List  Processing  to  the  Detection  of  Arterial 
Lesions  by  a  Labeled  Cell  Index",  applied  an 
Innovative  single-pass  algorithm  to  detect  and 
recognise  objects  for  subsequent  detailed 
analysis.  During  a  summer  at  graduate  school, 
Mr.  Cupak  was  a  private  consultant  for 
Schenectady  County  Community  College,  where  he 
designed  and  Implemented  a  student  Information 
system  In  COBOL. 

Mr.  Cupak  was  a  prograsmer/analyst  for 
che  Sew  York  State  Department  of  Environmental 
Conaervailon  (DeCon)  Administrative  Services, 
where  he  designed  and  Implemented  the  Pesticide 
Reporting  System  using  COBOL  and  MAKK-IV.  In 
addition,  he  was  responsible  for  supporting 
small  game  and  turkey  wildlife  management 
analysis  programs. 
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program  at  the  Pennsylvania  State  University 
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tion  to  Ada,  and  Advanced  Ada.  He  was  instru¬ 
mental  in  causing  Data  General  to  donate  a 
MV-1000  Ada  Development  Environment  to  Penn 
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1.  "Application  of  List  Processing  to 

Detection  of  Arterial  Lesions  by  a 
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2.  "MULTICS  Remote  Data  Entry  System", 

RADC-TR-79-265 

3.  Co-author  -  "B-Trees  for  Directory 

Organisation" 

A.  Internal  project  study  -  "Ada/PDL 
Comparisons",  1984,  "Ada  Course", 
1986,  and  "00D  with  Ada",  1987. 

Mr.  Cupak  belongs  to  the  Association  for 
Computing  Machinery  (ACM),  the  ACM  SICAdn, 
and  the  1CCP  societies.  Mr.  Cupak  is  the 
chairperson  for  che  HRB-Singer  Ada  Technical 
Working  Group  and  is  a  member  of  the  Singer 
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DEVELOPING  A  UNIVERSAL  Ada  TEST  LANGUAGE 
for  GENERATING  SOFTWAREySYSTEM  INTEGRATION 
and  FAULT  ISOLATION  TEST  PROGRAMS 


by  Jehuda  Ziegler,  Jerry  M.  Gratso,  Linda  G.  Burgermeister,  Leonard  D.  Mollod 
ITT  Avionics,  390  Washington  Avenue,  Nutley,  NJ  07110-3603  (201)  284-2030 


ABSTRACT 

ITT  Avionic#  ha#  developed  a  Universal  Ada  Te#i  LnngiLige 
(UATU  for  writing  automated  te#t  program#  to  perform 
extensive  real  time  software/system  performance  testing  and 
factor)*  product  ion/fie  Id  maintenance  fault  detection/ 
isolation.  The  UATL  wa#  developed  a#  a  STARS  (Software 
Technology  for  Adaptable  Reliable  System#)  Foundation# 
project  to  provide  support  to  the  replacement  of  ATLAS. 
BASIC,  and  other  special  purpose  test  control  languages  with 
Ada.  The  UATL  consists  of  a  set  of  portable  Ada  packages 
that  provide  the  user  with  a  complete  complement  of 
standardized  reusable  test  functions.  These  functions  include 
an  interactive  menu  driven  test  manager,  on-line  operator 
controls/displays,  real-time  “closed  loop"  test  data  stimulus/ 
response,  instrument  control  drivers,  test  data  recording,  and 
both  ASCII  and  grapnical  data  reduction  analysis.  Currently, 
the  UATL  suppons  driving  a  software  unit-under-test 
(UUT)  over  internal  memory,  or  a  hardvare  UUT  with  a  set 
of  stimulus  and  measurement  instruments  over  IEEE  -188 
and  MIL-STD-1553B  interfaces.  It  has  been  designed  to 
readily  support  the  addition  of  more  reusable  test  control  or 
analysis  functions  to  the  UATL  “test  language"  library,  and 
allows  the  user  to  develop  any  imique  test  functions  at  tlte 
Ada  code  level. 


INTRODUCTION 

DoD  directive  3405.2  |1)  specifies  Ada  as  the  prtftrrai 
language  for  generating  automated  test  progrants.  It  is  not 
required  at  present  because  of  the  staitdardized  test  support 
functions  currently  available  in  ATLAS.  However,  the  long 
range  goal  is  to  transition  all  DoD  software  to  Ada  (2|. 

The  major  strength  of  tlte  ATLAS  language  has  been  its 
ULIT  test  signal  oriented  vocabulary'  that  can  be  used  to 
specify  tests  that  are  independent  of  the  specific  test  station 
in  use  |3).  The  UATL  instrument  control  procedures  have 
been  modeled  after  the  ATLAS  constructs  to  retain 
familiarity  with  this  IEEE/ANSI  standard  test  language  |4] 
and  make  the  transition  to  Ada  relatively  straightforward  and 
cost  effective. 

However,  although  ATLAS  can  support  hardware  fault 
detection/  isolation  testing,  it  cannot  be  used  to  perform  real 
time  software/system  integration  testing.  ATLAS  is  limited 
in  its  support  of  digital  testing,  does  not  provide  the  real 
lime  high  data  rate  throughput  that  is  necessaty  for 
integration  testing,  and  does  not  contain  any  constructs  for 
data  recording  and  reduction  capabilities  needed  for 
extensive  software/system  performance  analysis. 


Software/systcm  development,  acceptance,  and  maintenance 
(regression)  testing  has  traditionally  been  performed  with 
special  purpotr  test  equipment  controlled  by  non-standard 
test  scenario  languages.  The  DoD  Computer  Programming 
Language  Policy  directives  (1,2)  do  not  address  the  issue  of 
standardising  integration  test  control  languages. 

The  UATL  has  been  designed  as  a  general  multi-purpose 
test  language  ih.it  provides  a  consistent  framework  for 
testing  at  alt  phases  of  the  software/system  development, 
production,  ant)  maintenance  life  cycle.  It  support#  extensive 
real  time  software  integration  testing  at  the  CSC/CSCI  level 
within  a  host  development  processor  over  a  tasking  mailbox 
interface  (Fig.  I),  and  hardware/software  Integration  testing 
or  hardware  fault  detection/isolation  of  a  complete 
system/subsyf sun  over  MII.-STD-I553B  and  IEEE  488 
interfaces  (Fig,  2). 

Adit  introduces  tlte  advantages  of  built-in  multi-tasking 
support,  extensive  data  consistency  checking,  portability  and 
reusability  of  tecurring  test  functions,  and  compiled  code 
that  runs  much  faster  than  ATLAS. 

By  supporting  extensive  software  integration  testing  in  the 
host  processor  software  development  environment  the  UATL 
encourages  the  rapid  prototyping  and  validation  of  system 
functions  early  in  the  development  process.  This  greatly 
reduces  the  number  of  untested  functions  that  must  be 
verified  on  the  final  system  hardware  where  test  resources 
are  usually  very*  limited. 
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Fig.  1.  Application  to  software  CSC/CSCI  testing  within  a 
standalone  host  processor  software  development  facility. 
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Of.  2.  Apptkatkxi  lo  hardware/soflwart  Inttfratkx*  and 
factory/malntenancc  fault  isolation  testing  over  the  system 
control  but  and  via  digital  control  of  various  lest 
devices/tatlruments  over  the  lest  control  but. 

Additional  UATL  component*  have  also  been  developed  to 
aid  teat  program  generation,  provide  on-line  operator  test 
control  and  monitoring  function*,  and  po«t-te*t  data 
reduction  and  analyti*.  Future  exteniion*  to  support  data  10 
over  additional  interfaces,  control  additional  test 
instruments,  or  accomplish  other  reusable  test  function*  are 
easily  added  to  the  UATL  test  support  library. 

As  pan  of  the  STARS  project  requirements,  portability  of 
the  UATL  software  has  been  demonstrated  by  operating 
both  on  a  VAXstation  II  under  VMS  and  on  an  IBM  AT 
compatible  (ITT  XTRA/286)  under  MS-DOS.  Portability  ha* 
been  designed  into  the  UATL  by  limiting  any  unique 
hardware  dependent  software  to  configuration  dependent 
package  bodies,  "separate"  procedures,  or  initialization  data 
Tiles. 

In  reality  it  turns  out  that  converting  ATLAS  test  programs 
to  run  on  different  test  stations  is  not  a  trivial  process  and  it 
will  be  just  os  cost  effective  to  convert  them  to  Ada  which  is 
much  more  supportive  of  portability.  An  automated  ATLAS 
to  UATL/Ada  conversion  tool  can  also  be  developed  to 
retain  the  existing  large  investment  in  ATLAS  test  programs. 

The  UATL  received  the  "Most  Innovative  Product"  award  at 
the  STARS  Current  Products  tint I  Future  Directions  Workshop 
held  Nov.  28  -  Dec.  2,  1988  in  Arlington,  VA. 

ADVANTAGES  IN  USING  Ada 

Current  arguments  for  the  support  of  ATLAS  (5.6]  are 
related  to  the  availability  of  readable  higher  level  test 
(station  independent)  commands  in  ATLAS.  With  the 
development  of  the  UATL  and  its  reusable,  standardized 
Ada  test  procedures  labeled  with  the  long  readable  names 
supported  by  Ada,  most  of  these  arguments  are  removed. 

There  are  also  many  advantages  for  using  Ada  as  the 
standard  test  control  language.  In  most  current 
implementations,  the  fault  detection  and  isolation  programs 
for  on-line  BIT,  factory  production  test,  and  for 
organizational,  intermediate,  and  depot  level  maintenance, 
are  rewritten  independently  in  various  languages  to  run  on 
the  actual  system  hardware  or  the  different  test  stations.  By 


standardizing  on  the  use  of  Ada  for  all  the  test  software, 
these  multiplicative  efforts  will  be  eliminated  resulting  in 
both  non-recurring  test  program  development  and  recurring 
maintenance  cost  savings.  Ada  supports  the  development  of 
portable  application  test  program  packages  that  detect  and 
isolate  faults  in  the  UUT  to  the  LRU/SRU  (line/shop 
replaceable  unit)  and  component  level.  The  appropriate  test 
packages  are  then  "wiih”cd  in  and  used  as  required  by  the 
test  programs  for  each  target  test  station. 

The  UATL  was  designed  to  provide  ns  many  reusable  test 
functions  as  possible  to  reduce  the  test  generation  effort,  but 
It  does  not  restrict  tlte  user  front  generating  any  unique  test 
controls  at  the  Ada  code  level.  Since  ATLAS  is  an 
interpreted  language,  it  restricts  the  user  to  what  is  defined 
in  the  language  and  what  is  supported  by  the  ATLAS 
compiler  and  run  time  executive  (interpreter)  in  each 
specific  test  station.  When  instruments  with  new  functions 
become  available  many  current  ATLAS  implementations 
require  the  user  to  import  compiled  code  (such  as 
FORTRAN)  to  accomplish  the  required  test  task*. 

The  strong  Ada  data  type  checking  can  also  be  used  to 
guarantee  that  the  test  data  is  consistent  with  the  UUT  by 
"with“ing  in  the  actual  Ada  interface  data  specifications 
from  the  software-under-test  in  the  UATL  based  test 
programs,  the  Ada  compiler  will  automatically  verify  that  the 
test  data  is  consistent. 

The  faster  operation  pihout  an  order  of  magnitude  in  many 
cases)  of  compiled  Ada  code  compared  to  interpreted 
ATLAS,  will  considerably  reduce  system  MTTR  (mean  lime 
to  repair)  with  its  resultant  recurrent  time  and  cost 
reductions.  The  Ada  multi-tasking  capability  also  supports 
the  running  of  parallel  digital  and  analog  (when  the 
instruments  are  available)  test  functions  which  also  improve 
the  test  throughput  for  a  given  set  of  test  station  resources. 
The  performance  tests  written  in  ATLAS  for  intermediate 
level  maintenance  testing  of  some  of  the  more  complex 
LRUs  on  a  major  project  at  ITT  Avionics,  take  several  hour* 
to  run,  and  ten*  of  hour*  to  link,  on  the  Advanced  Electronic 
Warfare  Test  Set  (AEWTS).  There  is  thus  much  room  for 
improvement  in  this  area. 

The  design  of  the  UATL  has  also  been  driven  by  the  STARS 
requirement  for  portability.  The  UATL  software  was 
developed  on  a  VAXstation  II  and  ported  to  an  ITT 
XTRA/286  (IBM  AT  compatible).  The  Ada  specifications 
and  all  the  higher  level  code  are  common  to  both  the  VAX 
and  XTRA  implementations.  The  unique  software  that  was 
required  to  interface  with  and  control  the  different  target 
hardware  was  limited  to  configuration  dependent  package 
bodies  and  "separate"  procedures. 

Ada  truly  lives  up  to  its  portability  claims.  Less  than  3Cp  of 
the  code  had  to  be  modified  in  order  to  port  to  the  ITT 
XTRA,  mainly  in  order  to  interface  with  the  different  1553 
and  IEEE  488  interface  hardware.  The  only  restrictions  that 
we  found  on  rehosting  the  UATL  software  to  the  ITT  XTRA 
were  in  the  memory  management  limitations  of  the  MS-DOS 
operating  system  and  in  some  of  the  optional  (chapter  13) 
Ada  language  functions  that  were  not  tested  by  the  Ada 
validation  suite.  These  problems  will  disappear  when  the 
chapter  13  functions  are  tested  and  with  a  more  robust 
operating  system  such  as  UNIX  or  PS/2. 
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Ad*’*  portability  will  enable  the  UATL  to  be  eatily  rehotted 
to  newer,  fatter  procettort  at  required  to  meet  test 
requirement*.  The  UATL  will  thut  never  become  restricted 
by  obtoiete  procettort  that  may  have  been  built  into  tett 
station*  tuch  at  it  currently  the  cate  with  ATLAS. 

We  have  found  that  Ada  alto  greatly  improve*  the  quality 
and  productivity  of  the  toftware  engineering  procet*.  The 
entire  UATL  effort  contitting  of  the  detign,  code,  and 
integration  tetting  of  1,044,560  byte*  of  generated  object 
code,  including  the  recoding  of  24,012  byte*  for  the 
rehotting  to  the  ITT  XTRA,  was  completed  and 
demonttrated  in  a  12  month  period  by*  a  team  of  5  toftware 
engineer*. 

In  addition,  many  CASE  (computer  aided  toftware 
engineering)  tool*  are  commercially  available,  or  being 
developed,  that  tupport  toftware  development  and 
maintenance  in  Ada. 

BASIC  UATL  FUNCTIONS 

UATL  tett  tupport  function*  are  provided  for  Tett  Program 
Generation,  On-line  Tett  Operation,  Real-time  Tett  Control, 
and  Pott-Tett  Data  Reduction.  The  interactive  menu  driven 
Tett  Manager  help*  manage  the  tett  station  and  tett  program 
configuration  and  provide*  menu  driven  control*  for  creating 
and  running  tett  and  data  reduction  program*,  The 
Control/Ditpiay  support*  On-line  Tett  Operation,  and  the 
Trajectory  Computation  function!  are  uted  to  support  both 
On-line  Test  Operation  and  Pott-tett  Data  Reduction 
analytit. 

The  UATL  hat  been  detigned  with  a  building  block,  layered, 
approach.  Each  reusable  test  function  it  provided  with  a 
standardized  Ada  Interface  specification  to  the  next  higher 
level.  The  *ei  of  Ada  packages  for  each  function  was  alto 
separated  into  common,  portable,  compilation  unit*  and 
configuration/hardware  dependent  package  "bodies"  and 
"separate"  procedure*.  Where  practical,  the  UATL 
component*  were  detigned  to  be  configurable  via  ASCII 
configuration  filet  that  are  read  during  test  initialization. 
Thit  allow*  the  maximum  portability  of  the  UATL  to  various 
tett  station  configurations. 

At  illustrated  in  Fig  3.  the  Stimulut/Retponte. 
Control/Display,  Data  Recording,  Data  Reduction,  and  IEEE 
488,  MIL-STD-1553B,  and  Internal  Memory  Digital  I/O 
CSC*  provide  a  complete  digital  tett  capability  and  form  the 
baseline  to  which  the  additional  tett  functions  arc  added. 
The  Stimulut/Retponte,  Digital  10,  and  Data  Recording 
functions  support  the  real  time  running  of  the  automated  tett 
programs.  The  Control/Display  function  provides  on-line 
operator  tett  control!,  and  the  Data  Reduction  function 
provides  a  detailed  off-line  analysis  capability. 

Digital  I/O  Function 


The  Digital  JO  function  provides  the  ability  to  interface  a 
UATL  based  test  program  to  the  UUT  over  various 
interfaces.  Currently  (Fig.  3)  three  packages  are  provided 
with  procedure trta sic'/  for  sending  and  receiving  messages 
via  the  MIL-STD-1553B  and  IEEE  488  buses,  or  via  an 
internal  memory  mailbox  interface.  This  can  easily  be 
expanded  to  add  packages  for  controlling  I/O  over  other 
interfaces  such  as  the  new  standard  VXlbus  for  instruments. 


The  Digital  10  CSC*  have  been  detigned  to  insure  maximum 
portability  by  limiting  the  hardware  specific  code  to 
configuration  dependent  package  bodies  and  "separate" 
procedure*.  Thi*  ha*  been  demonstrated  in  the  rehotting  of 
these  packages  from  the  MicroVAX  and  its  Q-bu*  bated 
interface  card*  to  the  ITT  XTRA  with  it*  PC-bus. 
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Fig.  3.  Basic  UATL  component*  and  their  interfaces.  The 
design  tupport*  the  addition  of  package*  to  handle  digital 
10  over  additional  interfaces,  control  various  test 
instruments,  perform  data  analysis,  etc. 

It  should  be  noted  that  these  CSC*  have  been  designed  to  be 
of  general  utility  and  can  be  used  a*  standalone  reusable 
interface  drivers  by  any  Ada  software  to  interface  with  the 
IEEE  488  or  MIL-STD-1553B  buses  or  to  other  tasks  within 
the  tame  processor  via  mailbox  messages. 

Data  Recording  Function 


The  Data_Recording  CSC  provide*  procedures  for  on-line 
recording  "of  all,  or  selected,  test  data  on  disk  or  magnetic 
tape  cartridge  for  use  in  detailed  off-line  data  reduction 
analysis.  This  function  is  necessaty  in  order  to  allow  the  test 
program  to  run  in  real  time  and  collect  the  data  for  detailed 
post  test  analysis.  The  only  analysis  that  is  required  to  be 
accomplished  in  real  time  is  what  is  needed  to  interactively 
change  the  test  operation. 

Stimulus  Response  Function 


The  Stimulus Jlesponse  CSC  provides  the  capability  to:  send 
stimulus  messages  at  a  specified  time  and  rate  with  the 
ability  to  vary  the  value  of  selected  fie!d(s)  on  each  output, 
save  and  compare  output  responses  from  the  UUT  and 
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determine  if  they  are  received  within  specified  response 
timeout*,  modify  the  te*t  sequence  by  activating/deactivating 
event*  bated  on  received  trigger  retponte*.  and  detect  fault* 
bated  on  the  reception  of  incorrect  or  non-reception  of 
expected  data. 

A*  illuttrated  in  Fig.  4,  the  UATL  provide*  three  basic 
event*  for  controlling  test  operation:  ttimulut,  retponte  and 
trigger  task*.  Multiple  event*  can  be  run  in  parallel  under  the 
Ada  tasking  model.  The  ttimulut  tatk  tend*  mettaget  to  the 
UUT  via  tnc  Digital  10  interface  handler*.  The  retponte  tatk 
receive*  mettaget  from  the  UUT  and  call*  the  comparator 
tatk*  at  required.  The  trigger  tatk  it  uted  to  effect  real-time 
tett  tequencc  change*  in  reaction  to  mettaget  received  from 
the  UUT  by  activating/deactivating  (triggering)  other  event*. 
Direct  control  of  the  UATL  event*  it  alto  provided  via 
procedure  call*  from  the  uter  tett  program. 


Fig.  4.  Stlmulut/Re* ponse  Tatk*  and  their  Interaction*  with 
the  uter  tett  program  and  UUT. 

The  ttimulut  event  it  defined  by  a  list  of  metsage*  and  the 
rate  at  which  they  are  to  be  trantmitted.  Trantmission  of  the 
entire  list  can  be  repeated  by  the  specified  circulate  count, 
and  rettaned  by  the  specified  cycle  count.  A  modifier  tatk, 
which  will  be  called  to  modify  the  message  before  its  output, 
can  also  be  assigned  to  each  message.  Each  event  can  be  set 
to  run  freely  without  interruption,  wait  at  the  first  cycle  for  a 
trigger,  or  wait  at  the  start  of  every'  cycle  for  a  trigger  event. 

The  response  event  is  specified  with  a  set  of  storage  buffers 
to  save  received  messages  from  the  UUT.  Other  buffers  can 
be  defined  to  ta'-^  the  indexes  which  point  to  the  saved  error 
responses,  t*  i  emr  response  receive  count.  The  error 


status  of  a  particular  response  it  determined  by  the  uter 
supplied  comparator  tatk*.  A  "no  retponte"  timeout  error 
condition  can  alto  be  determined  if  no  match  it  found  for 
the  expected  messages.  The  retponte  event  alto  hat  the 
capability  to  interrogate  devices  on  the  interface  to  elicit  a 
response  controlled  via  the  response  delay  timing  parameter. 

The  trigger  event  i*  defined  at  a  list  of  ttimulut,  retponte, 
or  other  trigger  tasks  that  are  to  be  activated  or  deactivated 
when  the  trigger  occurs.  A  trigger  occurrence  it  determined 
by  a  mateh  condition  returned  by  the  associated  comparator 
tatk.  Each  trigger  task  can  alto  be  tet  to  sequence  through  a 
trigger  list  each  time  the  current  trigger  is  satisfied  by  a 
"match". 

The  block  wait  function  is  alto  available  to  halt  execution  of 
the  "main"  tett  procedure  until  the  group  of  event*  with  a 
specified  block  name  are  completed.  Block  completion  can 
be  specified  as  the  completion  of  all,  or  just  the  first,  event 
in  the  block.  The  UATL  will  shut  down  all  events  in  a  block 
before  returning  control  to  the  test  procedure. 

Controt/DUplay  Function 


The  Control/Display  function  provides  the  operator  with  the 
ability  to  monitor  and  control  the  on-line  test  program 
execution.  The  operator  can  activate,  deactivate,  and  control 
the  operation  of  the  tests,  on-line  test  analysis,  and  data 
recording.  The  control  display  function  also  supplies 
subroutines  which  suppon  the  input/output  of  messages 
between  the  test  program  and  the  operator. 

The  liter  tett  program  ha*  the  option  of  activating  the 
Controls  Display  function  by  calling  a  supplied  procedure. 
Once  this  call  is  exectned  the  initial  screen  with  the  main 
menu  is  displayed. 

Main«>  REcording  RUn  STatistics  TRaffic  MEssage  QUit 

The  'RUn'  command  will  start,  and  'QUit'  will  stop,  test 
execution.  The  'REcording'  option  allows  the  user  to 
activatefterminate  data  recording  or  modify  the  list  of 
messages  (identified  by  Batch  ID)  that  will  be  recorded. 

The  'STatistics'  option  provides  a  real  time  monitor  display 
of  overall  tett  execution.  As  illuttrated  in  Fig.  5.  this 
displays  how  many  messages  for  each  batch  ID  have  been 
exchanged  over  each  interface.  The  statistics  display  has  a 
menu  which  allows  the  operator  to  scroll  through  all  the 
selected  batch  ID's,  change  the  list  of  selected  messages  to 
be  counted,  freeze  the  screen  update,  go  to  the  TRaffic 
display,  or  go  to  the  MEssage  Display. 

The  'TRaffic'  option  provides  the  real  time  display  of  the 
current  message  traffic  being  exchanged  with  tlte  UUT.  As 
shown  in  Fig.  6  the  last  five  messages  exchanged  in  each 
direction  are  displayed  nt  any  given  time.  The  operator  has 
the  option  to  select  which  messages  will  be  displayed,  freeze 
the  screen,  go  to  the  STatistics  display,  or  go  to  the  MEssage 
display. 
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Fig.  5.  Sample  Message  Statistics  Monitor  Display  Screen 


Massafa  Traffic  Data 

Mtmftt  HUUT 
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14  0204  0404  OAOC 

2 

114439 
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Fig.  6.  Sample  Message  Traffic  Data  Monitor  Display 
Screen 

The  Control  Display  function  also  provides  procedures  which 
can  be  called  from  the  user's  test  program  to  display 
messages  to,  and  receive  input  from,  the  test  operator.  The 
Operator  Message  and  Operator  Alert  (flashing  output) 
procedures  display  a  message  at  the  bottom  of  the  current 
control  display  screen,  and  the  Operator  Prompt  procedure 
displays  a  message  and  waits  for  an  operator  response. 

The  ’MEssage’  option  provides  a  real  time  display  screen  for 
the  operator  display  and  prompt  messages.  The  most  current 
messages  are  displayed  on  the  screen  with  an  arrow  pointing 
to  the  latest.  When  the  other  displays  are  activated,  the 
operator  messages  are  displayed  at  the  bottom  of  the  screen. 

Data  Reduction/Analysis  Function 


Data  Reduction  provides  both  ASCII  and  graphical  support 
functions  for  analyzing  the  recorded  test  data. 

For  a  tally  of  all  the  messages  in  the  recorded  file,  and  an 
indication  of  whether  any  messages  output  to  recording  did 
not  get  recorded,  the  user  calls  the  Message_Stati$tics 
procedure  with  a  control  table  indicating  the  IDs  of  the 
recording  batches  to  be  counted  and  the  output  print  file 


name.  This  creates  the  message  count  statistics  print  file 
illustrated  in  Fig.  7. 


MESSAGE  STATISTICS  PRINTOUT 

Test  :  wka  J  Run  ;  SR:  10SA 

START  TIME  :  2/11/1911  10:24:29.10 


Batch  10**|  1SS1B  ILEC4II  INTERNAL  LOCAL  |  Total* 


0  1 
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0 
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1  1 
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1 
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to 
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s 

2 
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-  00:00:52. 

.93 
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15 

00:01:10  16 

-  00:02:23, 

.45 

135 

157 

00:10:05.36 

-  00:12:37, 

.29 

Fig.  7.  Sample  Data  Reduction  Message  Statistics  Printout 

For  a  printout  of  the  recorded  message  contents,  the  user 
calls  the  Message_Printout  procedure  with  a  control  table 
indicating  the  IDs  of  the  recording  batches  to  be  printed  and 
tlte  output  print  file  name.  If  an  application  dependent 
reduction  task  is  not  provided,  then  the  default  printout 
shown  in  Fig.  8  of  the  decoded  UATL  defined  headers  and  a 
hex  dump  of  the  message  data  is  created.  If  an  application 
dependent  reduction  task  is  provided,  then  the  user 
determined  ASCII  strings  will  be  printed  for  the  message 
data  contents  following  the  message  header  printouts. 


MESSACE  DATA  PRINTOUT 


Test  :  WRA  5 

Run  :  SN  105  A 

START  T1UE  :  5/25/1916 

01:51:12.10 

MESSAGE  ::  Butch  ID 

at 

0 

Sent  at:  00:00:01.17 

Sequence  Nuaber 

as 

l 

Data  Ryle  Count  »  26 

Interface 

m 

LOCAL 

MESSAGE  ::  Batch  ID 

m 

14 

Sent  at:  00:00:03.06 

Sequence  Nuaber 

to 

3 

Data  Byta  Count  «  6 

Interface 

as 

I1553B 

RT  -  l  TRANSMIT  Subaddr  ■ 

-  17  Word  Count>3 

0401  0000  0052 

MESSAGE  ::  Batch  ID 

m 

20 

Sent  at;  00:00:04.08 

Sequence  Nuaber 

as 

4 

Data  Byte  Count  •  21 

Interface 

m 

LOCAL 

UATL  EVENT  MESSAGE 

Block  :  SET  rOWR 

Event  : 

HP  PWR  LVL 

Interface  :  IEEE4SS 

State  : 

RUN  Trigger  Mode  : 

MESSACE  ::  Batch  ID 

at 

12 

Sent  at:  00:00:06.76 

Sequence  Nuaber 

as 

0 

Data  Byte  Count  -  22 

Interface 

as 

1EEE4SS 

Receivers  ■  6 
Message  Byte  Count 

■  16 

4C  45  56  45 

4C 

2D 

31  32 

30  2E  30  30 

20 

20 

20  20 
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MCSSACC  ;;  IMich  10  «  1  3<ml  *1  00:0009, SI 

Sequence  Xuaber  »  I  D*u  Hyi«  Couni  «  |2 

Interface  «  LOCAL 

t 1 1  TEST  IS  COMfLETE  I M ! I 


Fig.  I.  Sample  Data  Reduction  Message  Data  Printout 

For  general  reduction  analysis  the  user  calls  the  Message_ 
Analysis  procedure  with  a  control  table  indicating  the  IDs  o"f 
the  recording  batches  to  be  analyzed,  and  a  user  supplied 
application  dependent  analysis  task.  This  user  task  will  be 
passed  all  the  desired  recording  batches  for  analysis.  The 
user  can  output  the  results  his  analysis  as  ASCII  strings  that 
will  be  printed  or  as  plot  data  to  be  graphed. 

For  graphical  analysis,  the  UATL  provides  procedures  to 
create  either  bar  graph  (Fig.  9)  or  multi-line  x-y  plots  (Fig 
10).  The  UATL  procedures  will  create  tltc  graphs,  but  the 
user  must  provide  the  data  to  label  the  graphs  and  provide 
the  plot  data.  The  graphical  output  can  also  be  saved  in  a 
OKS  Metafile. 


TEST  MESSAGES 


INTERFACE 

Fig.  9.  Sample  Bar  Graph  Output  Screen/ Printout 


POWER  READINGS  VS  FREQUENCY 


FREQUENCY  (GHZ) 


Fig.  10.  Sample  X,Y  Plot  Graphical  Output  Screen/ Printout 

The  generic  Bur_Graph  package  provides  procedures  that 
allow  the  user  to  create  a  bar  graph.  The 
Initialize_Bar_gniph  procedure  allows  the  user  to  specify  a 
title,  x,  y  -axis  labels,  the  number  of  bars,  and  whether  the 
bars  will  be  vertical  or  horizontal.  The  Display_Bar_Graph 
procedure  allows  the  user  to  specify  the  size,  color,  and  fill 
shading  for  each  bar. 

The  generic  XY_Plot  packages  (for  integer,  float,  and  fixed 
data)  allows  the  user  to  specify  a  title,  x,  y  -axis  labels,  and 


the  number  of  curves  with  their  color  and  line  type.  Each 
plot  point  is  associated  with  a  selected  curve.  To  assist  in  the 
graphical  analysis,  curve  smoothing  and  least  squares  fit 
functions  are  provided.  The  trajectory  computations  package 
can  also  be  used  to  perform  position  accuracy  analysis. 

INSTRUMENT  CONTROL  FUNCTIONS 

As  illustrated  in  Fig.  II,  we  have  added  various  test 
instrument  drivers  that  translate  Ada  procedure  calls  into 
IEEE  488  btts  commands  to  control  various  test  instruments, 
to  the  basic  UATL  functions  described  above.  These 
instrument  drivers  are  supplied  at  several  levels. 

General  ATI.AS  type  test  commands  are  supported  by  the 
Functional  Instrument  Control  package.  This  enables  the 
user  to  write  test  station  Independent  programs  at  tlte  UUT 
level.  The  Functional  Instrument  Control  package  then 
converts  the  user  commands  to  specific  instrument  controls 
based  on  test  station  and  UUT  interface  device  configuration 
data. 

Instrument  controls  are  provided  through  the  instrument 
driver  packages.  A  standard  MATE-CIIL  (Modular 
Automated  Test  Equipment  -  Control  Interface  Intermediate 
Language)  instrument  driver  provides  bus  commands  that 
will  control  any  instrument  that  responds  to  the  Air  Force 
MATE  standard  C1IL  commands.  Instruments  that  have 
additional  capabilities  that  are  nor  included  in  the  C1IL 
standard  can  be  accessed  via  the  "alternate"  language 
command  drivers.  Specific  instrument  control  packages  are 
also  provided  to  process  commands  in  an  instrument's 
"native"  language.  Drivers  are  also  provided  io  control 
signal  switching  devices  that  are  used  io  route  stimulus  and 
measurement  data  to  the  appropriate  instruments. 

The  UATL  also  provides  a  library  of  reusable  generic  test 
programs  that  can  be  used  to  test  standard  components  of 
various  systems,  such  as  a  MIL-STD-1553B  interface,  an 
amplifier,  etc.  This  provides  test  capabilities  at  a  higher  level 
than  the  ATLAS  UUT  directed  commands  and  facilitates  the 
development  of  standardized  tests  for  similar  components 
included  in  various  systems.  This  also  greatly  reduces  the 
test  program  generation  effort. 

User  test  programs  "with"  in  these  instrument  and  higher 
level  test  control  packages  to  control  the  devices  on  the  IEEE 
488  instrument  bus.  Similar  packages  can  be  developed  to 
control  instruments  over  other  test  buses,  such  as  the  new 
instrument-on-a-card  VXIbus  standard,  by  modifying  the 
package  bodies  of  the  lowest  level  UATL  instrument  specific 
drivers.  The  UATL  instrument  control  specifications,  and  all 
test  programs  developed  with  them,  will  not  have  to  be 
modified.  It  is  expected  that  if  Ada  becomes  the  accepted 
test  language,  these  types  of  packages  will  in  the  future  be 
provided  by  the  instrument  and  test  station  vendors. 

Functional  Instrument  Controls 

The  Functional  instrument  Control  package  provides  test 
station  independent  instrument  controls  to  the  user.  These 
controls  are  Ada  procedures  which  provide  the  functionality 
of  ATLAS  statements  using  the  verbs  apply,  remow,  measure, 
wijy  and  read.  For  more  specialized  instrument  controls  the 
user  can  access  the  UATL  instrument  specific  packages 
directly.  For  reusable,  test  station  and  UUT  independent 
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Fig.  4.  Addition  of  Hut  Reusable  Standardized  Test  Programs,  Functional  Instrument  Controls,  and  Instrument  Specific 
software  drivers  are  provided  to  control  various  instruments  via  standard  CIIL  or  specific  (native  or  alternate  language) 
instrument  commands.  The  Functional  Instrument  Control  package  enables  the  user  to  write  test  programs  at  the  CUT  level 
and  converts  them  to  specific  instrument  commands  based  on  test  station  and  UUT  interface  device  configuration  data. 


tests,  generic  test  packages  can  be  built  up  from  the 
functional  instrument  commands.  The  functional  package 
provides  vinual  test  station  independent  controls  which  are 
then  mapped  to  the  physical  instruments  through  the  use  of 
an  ASCII  test  station  configuration  file.  Selected  functional 
instrument  control  procedures  and  data  types  for  the 
physical  quantities  that  are  used  is  provided  in  Figure  12 
below. 


MILLIMETER  ;  constant  METERS  :«  1.0E-3: 
CENTIMETER  :  constant  METERS  :«  1.0E-2: 
KILOMETER  ;  constant  METERS  ;»  1.0EJ; 

NANOSECOND  :  constant  SECONDS  ;>  1.0E-9; 

MICROSECOND  :  constant  SECONDS  :•  1.0E-6; 

MILLISECOND  ;  constant  SECONDS  ;»  1.0E-3; 

MINUTE  :  constant  SECONDS  00.0; 

HOUR  :  constant  SECONDS  3000.0: 

DAY  :  constant  SECONDS  :*  86400,0; 


Package  FUNCTION AL_INSTRUMENT_CONTROL_TYPES  Is 


subtype  METERS  is  FLOAT  range  FLOAT' 
subtype  HERTZ  Is  FLOAT  range  FLOAT' 
subtype  SECONDS  Is  FLOAT  range 
subtype  VOLTS  Is  FLOAT  range 
subtype  AMPERES  is  FLOAT  range 
subtype  WATTS  is  FLOAT  range 
subtype  OHMS  is  FLOAT  range 
subtype  DBM  is  FLOAT  range 


first. .FLOAT* last; 
first.. FLOAT’last; 
0.0.. FLOAT' last; 
10.0E3..+10.0E3; 
0.0..1.0E3; 

0.0. . 10.0ES; 

0.0.. FLOAT* last: 
-150.0.. +200.0: 


subtype  RF_FREQ  is  HERTZ  range  1.0E3. .2.0EB; 

subtype  MICR0VAVE_FRE0  is  HERTZ  range  2.0E9. .26.0E9; 
subtype  LICilT_FREQ  is  HERTZ  range  4.3E14.  .7.5EH; 

KILOHERTZ  :  constant  HERTZ  :»  1.0E3; 

MEGAHERTZ  :  constant  HERTZ  1.0E8; 

GIGAHERTZ  :  constant  HERTZ  :«  1.0E9; 


MICROWATT  :  constant  WATTS  :«  1.0E-6; 

MILLIWATT  :  constant  WATTS  ;>  1.0E-3; 

KILOWATT  :  constant  WATTS  1.0E3; 

MEGAWATT  :  constant  WATTS  :»  1.0E6; 

MICROVOLT  :  constant  VOLTS  :>  1.0E-S; 

MILLIVOLT  :  constant  VOLTS  :•  1.0E-3: 

KILOVOLT  :  constant  VOLTS  X.0E3; 

MICROAMPERE  :  constant  AMPERES  :»  1.0E-8; 
MILL I AMPERE  :  constant  AMPERES  :»  1.0E-3; 

MILLIOHM  :  constant  OHMS  :•  1.0E-3; 
KILOHM  :  constant  OHMS  1.0E3; 

MEGOHM  :  constant  OHMS  :»  1.0E8; 


end  FUNCTIONAL_INSTRUMENT_CONTROL_TYPES; 
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with  n*CT :  ON  AL _1 N rrRU**XT_COrn*OL_TYREJ ; 
use  function  AL_tN5TRt»*xT_cowTitot_TYRts: 

hekm  ru*rr i on al_ i  KmnjNcirr_ccnm*o(.  i* 


procedure  CCT.RESOURCE 

(address  s  in  id.tyfe; 

CXAHTtO  l  OUl  MOUM: 

HOU)  !  in  RECCIVE.CALLS  ;»  WAIT; 

HOLD.TIMC  ;  In  DURATION  :«0.0); 

procedure  release.resource  i  adores $  :  in  id.tyfei; 
procedure  ARrLY.AC.FRCQUENCY 


(USING 

:  in 

LOGICAL.OCVICC; 

FREQUENCY 

i  In 

HERTZ; 

ROWER 

;  in 

DtM; 

COWNECT.VIA 

:  In 

STRING  :» 

STATUS 

out 

DR1VER.STATUS) ; 

procedure  Al'RLY„SWERT_AC_FReOUr.NCY 

(USING  :  in  LOOICAL.DEVICE; 


START.FREQUENCY 

In 

HERTZ, 

STOP.FREQUENCY 

in 

HERTZ; 

FREQUCNCY.STtf 

in 

HERTZ; 

ROWER 

in 

DBM; 

STEP  .DURAT I ON 

In 

DURATION; 

CONNECT  VIA 

In 

STRING  :« 

STATUS  ; 

out 

DRIVER.STATUS) ; 

procedure  MEASURE. AC.FREQUENCY 

(USING 

in 

LOG I CAL.DCV I C E 

START  FREQUENCY 

in 

HERTZ; 

STOP  FREQUENCY 

in 

HERTZ; 

MCASUREO.rREQUENCV 

out 

HERTZ: 

CONNECT.VIA 

in 

STRING  :«  — ; 

STATUS 

out 

DRIVER.STATUS) 

procedure  MEASURE.AC  POWER 

(USINC  ;  in  LOGICAL  DEVICE; 

frequency  :  in  HERTZ: 

POWER  ;  out  DBM; 

CONMCTVIA  ;  in  STRING  ■*; 
STATUS  ;  out  DR1 VEH.STATUS ) ; 

procedure  measure  ac  voltage 

(USING  "  ;  in  LOGICAL  DEVICE; 

VOLTAGE  ;  out  VOLTS; 

CONNECT  HI  :  in  STRING  :»  — ; 

CONNECT  LO  ;  in  STRING 

STATUS  ;  out  DRIYEH.STATUS) ; 

procedure  measure  AC  CURRENT 

(USING  ■  :  In  LOGICAL  DEVICE; 

CURRENT  ;  out  AMPERES" 

CONNECT  HI  ;  in  STRING 

CONNECT  LO  :  in  STRING  **; 

STATUS  :  out  DRIVER  STATUS) ; 


end  rUNCTlONAL_INSTRUMENT_CONTROL; 

Fig.  12.  Selected  Functional  Instrument  Control  data  types 
and  control  procedures. 

Instrument  Specific  Controls 


Fig.  13  is  an  example  of  an  instrument  specific  package  for 
controlling  a  frequency  synthesizer.  Note  the  instrument 
specific  data  typing  that  restricts  the  general  physical 
parameters  to  those  supported  by  the  instrument.  Ada 
provides  constraint  checking  to  ensure  that  the  limits  are  not 
exceeded  during  operation. 


with  YVNCT I ON AL. 1 N3TR  INSERT  .CONTROL  TYRES; 
u*«  FUNCTlONAL.lNSTRUMCXT.CONTROCjrYRKS; 

package  C I CATRON I CS.I 0 1 I.FRr.QUtXCY.SYKTHES I ZER.TYRCS  i* 


-«  CtgAirontes  specific  ranges 
subtype  CICA.RREQUENCY.SWECR  TYRE  is 

HERTZ  range  l 00.0* MEGAHERTZ. .11  000.0* MEGAHERTZ; 
Subtype  GIGA.FRCQUENCY, SWEEP  STCR  TYRE  IS 

HERTZ  range  1.0 'MEGAHERTZ. . 11.000, 0* MEGAHERTZ; 

subtype  0 1 CA.RREQUENCY.MCasUREMEXT.TYRE  Is 

HERTS  range  SO.O'MECAHERTZ. .IS  OOO.O'MECAHERTS; 
Subtype  G i CA.OUTRUT.LEVEL.TYRE  1* 

DBM  range  -llB.B.lSO; 
subtype  SwtER.STtR.DURATlON.TYRE  Is 
DURATION  range  0.0001, .1000.0; 

end  G !  CATRON  I  CS_1 0 1  l.r RCQUENCY.SYKTHES  I  ZER.TYRES ; 


with  rURCTtONAL.lHSTRUMtXT  CONTROL  TYRES: 

use  runctional.in5trument"control“tyres: 
with  G i Catron i  cs.i  oh. frequenc y.s ynthes i zer.tyres ; 
use  C I  CATRON  I CS.I 01  S.FREQUENCY.SYNTHES 1 ZER  TYRES; 


package  G I CATRON I CS_1 0 1 S_r A EOUENC Y_S YXTHES I ZER  i« 


procedure  GENERATE  FIXED  FREQUENCY 
(BUS  ADR  :  ID.TYrE; 

FREQUENCY  :  GIGA  FREQUENCY  SNEER  TYRE; 
OUTRUT.LEVEL  :  CICA_OUTRUT  LtVEL"TYRE: 
STATUS  ;  out  CRIVER.STATUS); 

procedure  SET.rOWER  LEVEL 

(BUS.ADR  ;  ID.TYRE; 

OUTRUT.LEVEL  ;  CICA.OUTRUT  LEVEL  TYRE; 

STATUS  :  out  DRIVER  STATUS); 


procedure  CCNERATE.SWEER.rRCQUENCY 


(BUS.ADR 
START.FREQUENCY 
STOR.FREQUENCY 
RREQUENCY.STER 
LOCKED  OR  UNLOCKED 
OUTPUT  LEVEL 
SNEER  MOOE 
SWEER.STER  DURATION 
STATUS 


ID.TYRE; 
CICA_FREQUENCY_SNEER_TYRE; 

G I GA.FREQUENC Y  SNEER  TYRE; 
CICA.rREQUENCY.SWEER.RTCr  TYRE; 
SWEEP.TYRE  LOCKED: 
CICA.OUTRUT  LEVEL  TYRE: 
SWECR.MOOE  TYRE  SINGLE; 
SNEER.STEP  DURATION  TYRE; 

OUl  DRIVER  STATUS); 


end  G I CATRON I CS.I 01 $_FREQUENCY_5YNTHES I ZER ; 

Fig.  13.  Selected  Instrument  specific  data  types  and  control 
procedures  for  operating  a  Gigatronics  frequency 
synthesizer. 

Figure  14  presents  comparisons  of  ATLAS  to  UATL 
functional  and  direct  instrument  level  test  programs.  As  can 
be  seen,  the  meaningful  variable  and  procedure  names 
supported  by  Ada  make  the  code  just  as,  if  not  more, 
readable  than  the  mnemonic  type  ATLAS  commands. 


••  ATLAS  PROGRAM  EXAMPLE: 

200710  BEGIN,  TEST-BLOCK  S 
200720  APPLY,  AC  SICNAL  USING  ‘RFSRCL* . 
POWER  10DBM, 

FREQ  10E9HZ, 

CNX  VIA  J5  S 
200730  END, TEST-BLOCK  S 
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—  UATL  FUNCTIONAL  INSTKtXCJfT  CONTROL  TEST  rONMAT 

Arrtv.AC.rswtxcv 


(USING 

•> 

FREQUENCY.CaatERATOR.l 

FREQUENCY 

»> 

10,069.  —  HZ 

POWER 

«> 

10,0.  --  OHM 

CONNECT.VIA 

•> 

Jit 

STATUS 

-> 

STATUS) : 

»* 

uatl  instrument  srtctric  frocram  format; 


COS.SJA.ASJ. 
OCC.UVAX.U. 
DCC.WAX^OO. 
DEC  VAX STATION. 
CICATRONICS  10U. 
CICATRONICS  WO. 
Mr_14jlA. 

HP.436A. 

HP.S34SA. 

Hr  j] jja. 
HP_S9307A. 
HP.S8J0IA. 
KP.IStlA. 

NONE); 


SCT.SWITCH  --  To  connect  rr«qu«ney_C*n*r»ior  10 
4S 


(HUS  ADORESS 

•> 

12. 

SETTING 

*> 

Al. 

STATUS 

»> 

STATUS) 

CCNER'.TEFt X ED  FREQUENCY 

(RUN. ADR 

*> 

IS. 

FREQUENCY 

*> 

10.0E9. 

oumnr.LEVEL 

*» 

10. 0. 

STATUS 

*> 

STATUS) ; 

FI*.  14.  ATLAS  to  UATt.  bawd  test  program  comparitont 
for  applying  a  fixed  frequency,  fixed  power  kvd,  AC  signal 
lo  UUT  JS. 

Mapping  Of  Functional  To  Instrument  Specific  Controls 


The  signal-oriented,  UUT-level  Functional  Instruittcni 
Control  is  mapped  to  the  Specific  Instrument  Control  level 
via  logical  resource  translation,  switch  settings  and  Ada 
procedure  calls. 

The  user  test  program  calls  made  at  the  Functional 
Instrument  Control  level  are  concerned  only  with  the  logical 
resources  present  in  the  test  system  instntments  themselves. 
These  logical  resources  represent  capabilities  resident  in  the 
test  station  but  do  no  call  out  the  actual  instruments 
themselves.  The  UATL  gives  these  resources  recognizable 
names  as  pan  of  u  logical  device  list: 

type  LOCI CAL. DEVICE  Is  ( D I C 1 TAL.TO.ANALOG. 1 . 

DIGITAL  TO  ANALOG  2, 

ELECTRON IC.COUNTER.l . 
ELECTRONIC  C0UNTER.2. 
FREQUENCY  SYNTHES I ZER.l . 
FREQUENCY  SYNTHESIZER  2, 
FREQUENCY  CONVERTER^ . 
FREQUENCY_C0NVERTER_2 . 

I1S53  TESTER  1, 

iissj“tester_2, 

MULTIMETER.! , 

MULTIMETER  2, 

POWER  METER  I. 

POWER  METER.2. 
SPECTRUM.ANALYZER  1. 

SPECTRUM  ANALYZER~2 , 

SWITCH  1. 

SWITCH~2, 

UATL  COMPUTER  1, 

UATL  COMPUTER  2. 

NONE) : 

The  actual  instalments  supported  by  a  particular  test  station 
must  also  be  known  to  the  system.  The  UATL  gives  them 
names  as  pan  of  the  physical  device  list: 

type  PHYSICAL  DEVICE  is  (BOONTON  4200 
CDS.S3A.352, 


In  addition  to  the  actual  physical  device  to  be  used  in  the 
Functional  Instrument  Control  call,  the  test  station  needs  to 
know  the  address  of  that  physical  device  on  the  488  bus.  In 
the  UATt.,  the  IEEE-488  interface  software  is 
programmable  to  handle  instruments  which  terminate  with 
CR.LF  or  instruments  which  use  the  service  request  as  pan 
of  their  operations,  it  also  implements  a  protocol  for 
communicating  between  computers  hosting  UATL  based  test 
programs. 


The  mapping  between  the  logical  and  the  physical  resource 
is  performed  by  reading  a  test  station  configuration  file  at 
program  initialization.  This  is  performed  in  the  "body"  of 
the  Functional  instrument  Control  package.  The  following  is 
an  example  of  a  UATL  configuration  file  for  mapping  the 


48S  address  and  protocol: 

POWER.METER.l 
FREQUENCY.S YKTHES I ZCR  I 
MULTIMETER  l 
DICITAL.TO.ANALOC  I 
SrECTRUM  ANALYZER  I 
SWITCH. 1 


HP.436A 

CICATR0KICS.101 I 

HP.343IA 

HP.SBS01A 

HP_IS#*A 

CDS  S3A.3S2 


i  given 

IEEE 

13 

SOL 

Lr 

06 

SOL 

LF 

23 

SOL 

LF 

02 

SOL 

LF 

IS 

SOL 

Lr 

24 

SOL 

Lr 

The  firsi  field  is  ihe  logical  resource,  the  second  is  the  actual 
instrument  used,  the  third  is  the  IEEE-488  bus  address,  the 
fourth  Is  the  protocol  used  (SOL  is  solicited,  which  means 
tire  unit  must  be  addressed  to  talk  in  order  to  get  a  response, 
it  does  not  issue  a  service  request),  and  the  fifth  is  the 
message  termination  (linefeed  for  ail  these  instruments). 
When  this  file  is  read  the  Functional  Instrument  Control  also 
initializes  the  IEEE-488  interface  software  to  operate 
according  to  the  characteristics  specified  for  the  instruments 
in  the  test  system. 


The  switch  settings  required  to  connect  the  physical  device  to 
the  specified  UUT  connection  are  determined  from  another 
configuration  file  which  contains  information  about  the  test 
station  switching  network.  The  required  devices  are  switched 
in  to  accomplish  the  Functional  Instrument  Control  call. 


Each  operation  returns  a  completion  status.  This  status 
indicates  the  success  or  failure  of  the  requested  operation. 
The  UATL  currently  returns  the  following  values  for  its 
operations: 


type  DRIVER_SrATUS  Is  (SUCCEEDED, 

FAILED. 

FUNCTION  NOT  SUPPORTED. 
PARAMETER  OUT  Or  RANGE. 

I NVAL1 D.MEASUREMENT . 

N0_ INSTRUMENT  RESPONSE. 
INSTRUMENT  NOT  ON  BUS. 
MEASUREMENT  UNDER~RANGE. 
MEASUREMENT" OVER  RAXCE. 
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*ntO#G  DEVICE  MOOT. 
DCVICt.TJWitXT. 

EXTWIX  AL  _1S  XCX  AL JtOT  JltCt !  VtO . 
COMMA  XO  3YXTAX  EXBOtt. 
AMetCOOGs.TlUXSLATIOK. 
BtMWuacc.aoT.caAXTto) . 

The  final  step  is  make  the  procedure  call  to  the  specific 
instrument  with  the  appropriate  bus  address.  The  best  way  to 
describe  this  is  by  way  of  example.  Consider  the  previous 
examples  of  the  logical  resource  handling  and  switching  as 
pertinent  to  this  example  and  a  call  is  made  to  apply  an  AC 
signal: 

AW.Y.AC_rSWUEaCY 

tvs  i*g  »>  ntwutacY.SYimt£SJ2£a_i. 

racoutv.rv  ■»>  ».oe». 

rowta  *>  -«s.o. 

coaxtxr.vix  ->  •yicjx*. 

STATUS  *>  SYSTEM, ST ATVS 1 . 

This  call  wants  to  place  a  $  Gigahertz,  -65  dBm  signal  from 
FREQUENCYJJYNTHESIZERJ  at  the  "YKiJN*  pin  of  the 
UUT.  The  resource  translation  Indicates  that  physical  device 
GIGATRONICSJQIS  at  bus  address  6  will  be  used.  The 
switching  logic  connects  the  physical  device  to  the  UUT  pin 
"YIGJN".  Then  a  call  is  made  to  the  Gigatronics  1018 
Frequency  Svnthesizer  package  procedure  to  GENERATE 
FIXED  FREQUENCY: 

CICAT*0KXC$_101»,rAEQUCMCY  SYKTMES I ZCR 
ccatxATtc„nxK>  rawutacY 
taus  Atm  •>  bus  ados css. 

rnEQUEacv  «>  racouotCY. 

OUTPUT  LEVEL  ->  POMEK, 

STATUS  ->  STATI ; 

where  BUS  ADDRESS  is  equal  to  6.  FREQUENCY  is  equal 
to  9.0e9,  and  POWER  is  equal  to  -65.0.  STAT  will  be  the 
status  returned  to  the  caller. 

By  design  the  instrument  level  package  procedure  call  looks 
very  similar  to  the  functional  level  call.  This  allow*  easy 
integration  into  the  Functional  Instrument  Control  scheme. 
This  is  adhered  to  as  much  as  is  practical,  but  when 
necessary  deviations  occur  the  functional  instrument  package 
will  perform  the  translation  from  the  standard  functional 
level  call  to  the  unusual  instrument  requirements.  Where 
possible,  similar  function*  in  different  instrument  level 
packages  will  also  have  the  same  procedure  profile.  This 
standardizes  the  Ada  instrument  driver  Interfaces  which 
makes  instrument  substitution  in  the  UATL  test  set  very 
easy. 

A  further  strength  of  this  approach  is  that  errors  are  trapped 
by  the  Ada  exception  mechanism  at  the  level  of  the  specific 
instrument  package  procedure  calls.  A  call  cannot  be  made 
to  the  instrument  package  with  parameters  that  are  out  of 
range. 

TEST  MANAGER 

The  UATL  Test  Manager  provides  a  menu  driven 
environment  in  which  a  user  can  create  and  ran  UATL  test 
and  reduction/analysis  programs.  As  illustrated  in  Figure  15, 
it  organizes  and  controls  the  test  station  environment  and 
provides  a  portable,  menu  driven,  access  to  all  the  system 
facilities. 

The  test  manager  prompts  the  user  to  configure  the  system, 
ran  any  test  or  test  analysis  program  in  the  directories, 


examine  the  test  results,  build  a  test  or  reduction/analysis 
progrant,  create  reusable  test  packages,  or  ran  any  of  the 
suppled  utility  |>rograms.  The  test  ntanager  provides  access 
to  the  UATL  builder  tool  that  guides  a  user  through  the  steps 
to  generate  UATL  test  and  data  reduction  programs,  and  to 
the  trajeciory  editor  that  enables  the  user  to  ereate 
simulation  test  trajectories.  The  test  manager  menus  also 
contain  choices  to  edit,  compile,  link,  delete,  enter,  and 
extract  files. 

The  user  does  not  even  have  to  be  concerned  with  the 
location  of  files  or  their  full  names.  The  UATL_Tcst_ 
ManagcrJTranslations  package  provides  a  set  of  functions 
that  will  translate  a  short  (user  supplied)  name  into  a  full  file 
name  that  contains  the  directory'  and  file  extension. 


Fig.  15.  Interface  block  diagram  for  the  UATL  Test 
Manager. 

GENERATING  A  TEST  PROGRAM 

An  applications  programmer  can  generate  u  test  program  by 
writing  an  Ada  main  program  procedure  that  uses  the  UATL 
components  to  initialize  and  control  the  desired  test 
operation.  To  simplify  the  process  for  the  non-sophisticated 
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user.  a  test  program  generation  tool  ha*  alio  been 
developed, 

A  UaTL  ba*ed  test  program  consist*  of  a  u*er  generated 
"main"  test  procedure  whkh  control*  the  desired  te*t 
function*  and  sequencing.  and  an  optional  ntodifkri 
comparator  package  whkh  contain*  the  tasks  invoked  for 
modifying  stimulus  or  comparing  re*pon*e  message*.  The 
UATL  te*t  generation  tool  (Fig.  li)  prompt*  the  u*cr  for  the 
defined  te*t  function*  and  automatkally  generate*  the 
"main"  te*t  procedure  and  modifier-comparator  ta*k* 
package  from  the  u*cr  *upp)kd  mc**agc*  and  modifier-? 
comparator  procedure*. 


UK*  UM* 


UM* 


WTUMMOUTt 
TUT  MACRO 

nu 


A*  TUT 

hwosmm 


IXKUTUU 

TUT 

OftOQftAM 


Fig.  Id.  Test  frog  ram  Genera  lion  Sequence  kiting 
Amounted  Tool,  liter  eon  tuptf/modify  the  let)  program  at 
each  of  the  indicated  point*. 

A  macro  language  ha*  been  created  a*  a  pan  of  the  ten 
generation  tod  to  aid  in  writing  te*t  program*  whkh  require 
complex  data  »tructure*.  e.g.  a  li*t  of  atimulu*  me**agc*. 
The*e  macro*  simplify  the  *pecification  of  the  *iimulu*, 
re*pon*e.  and  response  read  me**age*f  modifkr/comparator 
task*,  trigger  action*,  and  modifkricomparaior  tatk 
definitions. 


The  teat  generation  tool  con*i*t*  of  the  Tc*t  Builder  and  the 
Macro  Preproce**or.  The  builder  i*  an  interactive  program 
whkh  guide*  the  u*cr  through  writing  a  teat  program.  The 
teat  procedure  builder  pretent*  valid  UATL  function*  and 
option*  for  the  uter  to  select  and  supply  the  required  input. 
The  uter  input*  are  checked  for  proper  type  and  value 
before  being  accepted.  The  tool  automatkally  "with"*  in  the 
appropriate  UATL  package*  for  the  telecied  function* 
variables  of  the  proper  type  for  the  user-supplied  names. 
The  builder  then  prompts  the  user  for  the  information  to 
define  the  modifier/comparator  task*.  This  information 
includes  the  user-defined  procedures  that  will  be  called  for 
the  modify/compare  operation,  and  the  data  type  that  it  will 
process.  The  output  from  the  test  builder  is  a  UATL  test 
macro  file  consisting  of  Ada  code  with  embedded  macro*. 
The  macro  processor  inputs  the  macro  file  and  outputs 
compilable,  correct  Ada  code. 

Fig.  16  also  illustrates  the  test  program  generation  and 
modification  sequence.  The  user  can  enter  the  test  writing 
process  at  any  of  the  indicated  points.  The  test  program  can 
be  created  using  the  interactive  Test  Builder  tool,  and 
modified  or  created  by  editing  the  intermediate  simplified 
macro  or  Ada  source  files. 


The  generated  Ada  te*t  program  *ource  file*  are  then 
compikd  in  the  following  order:  u*er-*upplkd  message*, 
modifier- comparator  procedure*,  modifkricomparaior  task*, 
and  te*t  procedure  The  linked  object  file*  re*ult  in  an 
executable  UATL  ba*ed  te*t  program. 

Trajectory  Generator 


This  tool  provide*  a  menu  driven  editor  for  creating  and 
modifying  flight  profik*  for  the  UUV  and  other  simulated 
unit*  in  the  test  environment.  The  flight  profile*  are  defined 
by  wa>  point*  to  simplify  trajectory  (Hanning.  Waypoint*  are 
defined  by  three  dimensional  position  (x.y.x),  speed,  and 
turn  acceleration.  Two  stage  maneuver*  are  then  computed 
between  waypoint*:  constant  rate  and  altitude  turn*  heading 
toward*  the  next  waypoint  (with  coordinated  roll  and  yaw), 
and  constant  linear  accektation  to  reach  the  defined  speed 
at  the  next  waypoint’s  position.  This  “Closed  form" 
(non-integrated)  kinematic  solution  i*  j*d  to  assure 
repeatability  of  trajectory  scenario*.  Use  of  a  linked  list 
waypoint  data  structure  also  support*  dynamk  flight  profile 
change*  during  test  operation. 

Froccdure*  are  also  provided  to  supply  computed  trajectory 
position,  altitude,  and  velocity  for  the  UUT  or  any  of  the 
other  simulated  unit*  at  requested  test  scenario  time  marks 
based  on  the  defined  test  trajectories.  The  test  programs  can 
use  this  data  to  control  the  generation  of  test  stimuli  in  real 
time  with  propagation  delays  and  angular  dispersions  to 
simulate  motion  in  the  laboratory.  This  is  very  important  if 
meaningful  testing  for  functions  that  depend  on  UOT  and 
interacting  unit  motion  are  to  be  verified  in  the  laboratory. 

The  trajectory  compulsion*  package  can  also  be  used  in 
post-test  reduction  analysis  to  verify  the  navigation  accuracy 
of  the  recorded  test  data. 

USING  THE  UATL 

To  verify  the  UATL  software  and  to  illustrate  its  capabilities, 
several  software/system  integration  and  fault  detection/ 
isolation  demonstration  tests  were  developed. 

The  *ofiware/*y*tem  integration  demonitrations  (Fig.  17) 
included  running  a  set  of  UATL  test  driver  programs 
simulating  a  communication  system  interacting  with  its  host 
platform  and  other  network  participants.  In  a  typical  system 
the  host  platform  sends  messages  to  the  communication 
system  over  the  1553B  bus  for  transmission  over  the  RF 
network  to  other  participant*,  and  messages  received  from 
other  participants  by  the  communication  system  are  sent  to 
the  host  platform  over  the  1553B  bus  for  processing  and 
display  to  the  operator.  The  flexibility  in  changing  the 
interface  over  which  the  UATL  and  UUT  can  interact  was 
used  to  easily  change  the  test  configuration  as  -p'.ied  to 
various  stages  of  the  development  rv  r>s.  For 
demonstration  purposes  the  UATL  was  us*  *)  simulate 
each  of  the  interfacing  units  in  the  commur^  -ion  system 
environment.  At  any  point  in  the  process  the  real 
software/system  under  test  can  be  introduced  and  tested  with 
the  UATL  simulating  its  environment. 

First  software  integration  is  performed  for  ail  system 
elements  running  in  one  processor.  Then  by  placing  the 
communication  system  and  network  participants  simulators 
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D.  Communication  System  Integration  Test  Configuration 


Fig.  17.  Demonstration  of  software/system  integration  testing  or  an  avionics  communication  system.  The  UATL  can  be  used 
to  simulate  the  communication  network,  the  host  platform,  and  the  communication  system  to  drive  the  software/system 
under  test  in  various  configurations  by  using  the  appropriate  internal  memory  or  external  1553B  and  IEEE  4SS  Interfaces. 


in  a  processor  containing  a  1553B  interface,  it  can  be  used 
for  the  integration  testing  of  an  actual  host  platform  UUT. 
By  placing  the  host  plalform  and  network  participants 
simulators  in  one  processor  with  a  1553B  interface  and  an 
IEEE  488  interface  emulating  the  RF  hardware  (or 
controlling  a  real  RF  transmitter/receiver),  it  can  be  used  for 
the  integration  testing  of  an  actual  communication  system 
UUT.  For  the  demonstrations,  a  UATL  based  test  program 
was  used  to  also  simulate  the  UUT  in  all  the  test 
configurations. 


The  factory/mnimenance  test  demonstrations  consisted  of  a 
test  program  running  within  a  microVAX  or  ITT  XTRA 
processor  controlling  a  set  of  RF  test  instruments  to 
characterize  ti  breadboard  containing  two  RF  amplifiers  or  a 
breadboard  YIO  bandpass  filter,  and  controlling  a  1553B 
tester  to  perform  a  standardized  test  of  the  1553B  hardware 
installed  in  the  Microvnx. 
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Ada  IMPLEMENTATION  CONSIDERATIONS 

Some  of  ihe  issues  relating  10  the  Implementation  of  the 
UATL  in  Ada  and  the  related  design  decisions  are  described 
below.  These  arc  related  to  the  processing  of  test  data  by 
general,  reusable,  test  packages  and  application  specific  test 
requirements  with  the  strong  Ada  data  typing  and  with 
ponablity  issues. 

Passing  Generic  Dau  (The  Kyte  Array) 


One  of  the  critical  items  that  had  to  be  considered  in 
designing  the  UATL  was  in  providing  a  capability  for 
performing  the  same  sth;v,:us/re#ponsc  functions  for  a 
variety  of  application  dependent  data  types  simultaneously 
over  several  external  interfaces.  If  the  UATL  had  been 
restricted  to  just  concurrent,  independent  events  thg  UATL 
could  haw  been  adequately  implemented  using  generics  to 
instantiate  events  for  the  data  type  required.  Since  these 
activities  were  to  be  concurrent  and  mixed,  a  common 
method  of  control  was  needed. 

Thus  a  general  byte  array  data  formal  was  defined  to  pass 
within  the  UATL  stimulus/rcsponse  functions. 

subtype  DATA.BYTE  is  HATUAAL  range  0. ,2JS; 

type  BYTE  ARRAY  is  srrsy  (HATURAL  range  o) 

Of  DATA, BYTE; 
pragaa  PACK  (BYTE, ARRAY) ; 

type  RYTT,ARRAY_PTR  is  access  BYTE_ARAAY; 

The  byte  array  is  an  unconstrained  array  of  data  bytes.  User 
defined  data  objects  arc  convened  into  the  byte  array  using 
unchecked  conversion.  The  general  byte  array  form  is 
treated  merely  as  the  memory  image  of  the  user-defined 
data  type.  No  operations  are  performed  on  the  byte  array  by 
the  UATL  other  than  to  pass  it  to  the  appropriate  destination 
at  the  appropriate  time.  The  UATL  only  uses  the  length 
attribute  of  the  byte  arrays  in  its  processing.  This  is 
analogous  to  doing  low  level  i/O  wherein  the  object's  address 
and  byte  count  is  passed  to  some  device  to  perform  the  I/O 
operation.  When  the  byte  array  is  passed  to  an  interface  for 
transmission  it  is  convened  to  a  general  form  for  that 
panicular  interface.  Messages  received  from  a  panicular 
interface  are  convened  from  that  interface's  general  fonn 
into  the  UATL  geiteral  form  of  the  byte  array. 

—  General  sassage  fora  for  the  1553  interface 
type  US53_MESSACE 

(WORD.COUKT  ;  DATAJ*ORD_COUMT_TYPE  :■  0)  is 
record 

RT  ADORESS  ;  lD_TYrfi; 

CCRMARD  ;  COSBtAXD  TOE; 

SUBADDRESS  ;  SUB_ADDHESS ; 

ose  SORD,COUKT  is 
when  0  «> 

rULL.MESSACE;  WORD.ARRAY  (1..32); 
when  others  •> 

MESSAGE  :  WORD.ARRAY  fl. .WORD.COUNT) ; 
end  case; 
end  record; 

The  user  programs  process  the  application  dependent  data 
and  the  UATL  processes  the  general  reusable  message 
control  headers.  Whenever  this  data  appears  at  the  user  test 
level  it  is  convened  back  into  the  user's  data  type.  The 

UATL  provides  a  set  of  generics  to  perform  these 


conversions  in  a  consistent  manner.  The  user  instantiates  the 
generic  functions  for  the  types  to  be  convened  and  the 
UATL  conversion  generics  take  care  of  ensuring  that  it  is 
done  correctly. 

--  Generic  cornermen  function  io  convert  any  type  to 

—  an  equivalently  nised  byte  array  type. 

generic 

type  UATL.SOURCE  i*  private; 
function  COHVKRT.TO.BYTt  array 

(SOURCE  !  in  UATL.SOURCE)  return  BYTE.ARRAY; 

-•  Ceneric  conversion  function  to  convert  a  byte  array 

—  to  an  undUerluinaied  type  of  equal  or  greater  site 

generic 

typa  UATL.TARCET  is  private; 
function  COXVtRT.rRCM  am  ARRAY 

(IK, ARRAY  t  in  BYTE, ARRAY)  return  UATL.TARCET; 

-•  Generic  conversion  function  to  convert  a  byte  array 

—  to  a  type  with  one  discrialnant  of  equal  or  greater 
--  site 

generic 

type  UATL.DISCRIMIXAHT.TYPE,!  is  to); 
type  UATL.TARCET  IDISCI  ;  UATL.D I SCR I M I HAXT.TYPE.i ) 
is  private; 

function  COMVERT.Dl SCR I M I HATED, l 
UK,ARRAY  ;  in  RITE  ARRAY; 

DISC.)  :  in  UATL~DI5CRIMIHAHT_TYI*fi„l> 
return  UATL.TARCET; 

—  Ceneric  conversion  function  to  convert  a  byte  array 

—  to  a  type  with  two  discrialnant*  of  equal  or 

—  greater  sise 

generic 

type  UATL_D  I  SCR  1 M I K  AHT.TY  RE,  1  is  (O); 
type  UATL,D!SCR!MIXAXT  TYPE  2  is(Oi; 
type  UATL.TARCET 

(DISCI  :  UATL  DISCRIMIHAKT  TYPE  1; 

DISC2  :  UATL_DISCRIMIXAMT_TYPE"2)  is  private; 

function  COH VERT.D I SCR I M I HATED  2 
CIH.ARRAY  ;  in  BYTE  ARRAY; 

DISC, I  :  in  UATL.DISCR1MINAHT  TYPE.l; 

DISC.2  :  in  UATL_D!SCRIMIXAXT  TYPE.2) 

return  UATL.TARCET; 

The  use  of  ihesc  conversions  are  limited  to  passing  data  at 
procedure  and  task  calls.  Even  though  unchecked 
conversions  are  used  internally,  if  the  UATL  supplied 
conversion  function  for  the  correct  number  of  discriminants 
in  the  user  data  is  used  (compiler  checked)  then  the  correct 
object  is  obtained.  Additionally,  the  UATL  builder  tools  are 
constructed  to  make  the  use  of  these  conversions  very  easy. 

Passing  User  Denned  Procedures  (Task  Access  Objects) 


Another  problem  that  had  to  be  solved  in  developing  the 
UATL  was  the  need  io  pass  user  supplied  procedures  to 
perform  application  dependent  stimulus  modification, 
response  and  trigger  comparisons,  and  data  reduction 
analysis  to  the  general  reusable  UATL  test  functions.  Ada 
does  not  allow  the  passing  of  procedures  as  run  time 
parameters.  The  bnite  force  method  would  be  io  have  fixed 
named  procedure  specifications  ihat  are  called  from  the 
UATL  for  which  the  user  provides  applicaiion  dependent 
bodies.  This  technique  can  run  into  large  problems  in 
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managing  all  the  disparate  Ada  libraries  with  like-named 
user  defined  bodies. 

A  second  option  is  to  pass  task  access  objects  in  place  of  the 
procedures.  They  give  till  the  procedural  functionality 
required  and  can  be  passed  as  parameters.  The  problem  in 
the  UATL  domain  becomes  the  need  to  pass  dissimilar  task 
access  objects  to  a  general  set  of  stimulus/response 
functions.  The  UATL  requirement  for  concurrent,  mixed 
events  precludes  the  use  of  generics  in  the  UATL  events. 

It  was  thus  decided  to  use  a  task  type  template  concept  to 
accomplish  this  requirement.  The  UATL  defines  a  general 
form  of  the  modifier  and  comparator  tasks  that  contain  two 
entry  points;  one  for  passing  an  access  pointer  to  the  byte 
array  message  being  passed  to/from  the  task,  and  another  to 
terminate  the  task  gracefully.  The  message  parameter  is 
defined  at  '"in  out"  for  the  modifier  task  to  allow  its 
modification,  and  as  "in"  for  the  comparison  task  with  an 
"out"  parameter  for  the  result  of  the  comparison  match 
operation.  The  template  task  body  has  the  two  entry  points 
in  a  select  statement  encased  in  a  loop.  Included  in  this 
definiticn  is  an  access  type  to  the  general  task  type  template. 

The  user  writes  the  desired  modifier/comparator  tasks  in  the 
form  of  the  UATL  task  type  template  and  includes  the 
application  dependent  processing  in  the  task  body.  The  input 
byte  army  message  is  converted  to  his  own  object  type  using 
the  UATL  conversion  generics.  For  the  modify  operation  the 
user  modifies  the  message  in  his  own  type  definition,  and 
then  converts  it  into  the  byte  array  for  passing  to  the  UATL 
stimulus  task.  For  the  compare  operation  the  user  checks  or 
extracts  whatever  fields  he  chooses  from  the  message  in  his 
own  type  definition,  and  sets  the  returned  match  condition 
parameter  to  the  UATL  response/trigger  task.  The  modifier/ 
comparator  *  tasks  can  communicate  values  among 
themselves  by  sharing  a  common  data  area.  A  comparator 
task  can  save  a  value  from  a  UUT  message  field  that  a 
modifier  task  can  then  use  to  modify  an  outgoing  message. 
This  provides  the  real  time  "dosed  loop"  test  data  operation 
capability. 

The  last  step  in  the  process  is  to  pass  the  user's  tasks  to  the 
UATL  event  tasks  so  that  they  can  be  called  when  required. 
This  is  accomplished  by  an  unchecked  conversion  of  the 
user's  modifier/comparator  task  access  object  into  the  task 
access  object  which  the  UATL  events  are  expecting.  Since 
the  entry  point  specifications  and  parameter  profiles  are 
identical,  and  the  task  body  operation  similar,  the  UATL 
events  communicate  with  and  control  the  operation  of  the 
user's  task  as  if  it  were  a  task  of  the  UATL  general  form. 

—  UATL  Modifier/Comparator  T«tk  Templates  and  Types 

—  Ceraral  modifier  task  type  template. 
tr.sk  type  UATL  MOOiriEA  TASK  is 

prafaa  PRIORITY  (PRIORITY* laat) ; 
entry  uooirr  (CUM  :  in  out  byte  array  ptb) ; 
entry  TASK  COMPLETE; 
end  UATL_MOOlriER_TASK; 

--  General  Modifier  task  body  teaplate. 
task  body  UATL_MOO IFIER_TASK  is 
bee  in 
loop 
select 

accept  MOOirY  (CUM:  in  out  BYTE_ARRAY_PTR )  do 
null; 


end  MOOtrY; 
or 

accept  TA5K_C0MPLETt; 
exit; 
end  select; 
end  loop; 

end  UATL.MOOl TIER .TASK. 

—  Access  pointer  to  general  Modifier  task 
type  UATL.MOOima.TASK  ACCESS  is 

access  UATL.MQOiriER.TASK. 

—  List  of  access  pointers  to  general  Modifier  task 
type  L'ATL_MCO!riEX_TASK_LI5T  is  array 

(POSITIVE  range  ol  of  UATL.MOOI r I E* .TASK. ACCESS ; 

>>  Access  pointer  to  list  of  access  pointers  to  general 
modifier  task 

type  UATL.MOOI  HER.TASK  LIST. ACCESS  ts 
access  uatl.moo i pi er.task.l i st . 

--  General  comparator  task  type  teaplate. 
task  type  UATL .COMPARATOR .TASK  is 
pragaa  PRIORITY  (PRIORITY’ last); 
entry  COMPARE 

(CUM  ;  in  BYTE, ARRAY  PTR; 

MATCH .STAT  :  out  UATL  MATCH  STATUS) ; 
entry  TASK .COMPLETE; 
and  UATL.COMr AR ATORTASK ; 

--  General  comparator  task  body  teaplate. 
task  body  UATL_COMPARATOR_TASK  is 
begin 
loop 
select 

accept  COMPARE 

(CUM  ;  in  BYTE  ARRAY  PTR; 

MATCH  STAT  :  Out  UATL  MATCH  STATUS)  do 
MATCH  STAT  MATCH; 
end  COMPARE; 
or 

accept  TASKCOMPLETE; 
exit: 
end  select; 
end  loop; 

end  UATL_COMPARATOR_TASK ; 

For  the  actual  generation  of  a  test  program,  the  UATL 
Builder  tool  relieves  the  user  of  having  to  define  these 
template  tasks.  The  tool  is  structured  so  that  the  user 
supplies  a  package  of  modify  or  compare  procedures  that  he 
wants  to  use.  The  specification  of  the  modify  procedures  has 
one  "in  out"  parameter  of  the  user's  message  type.  The 
compare  procedure  has  an  "in"  parameter  of  the  user's 
message  type  and  an  "out"  parameter  of  the  resulting  match 
status.  The  UATL  builder  tool  will  automatically  construct  a 
package  of  task  types  and  task  access  types  with  the 
necessary  conversions  to  call  the  user  procedure  with  the 
message  that  it  is  expecting. 

The  interactive  builder  tool  prompts  the  user  for  the 
necessary  information  to  construct  these  tasks  and  creates  a 
user-editable  macro  file  as  shown  below. 

—  User  editable  todifier/Coaparator  macro  examples 


—  Modifier  Ta’ik 


•MOOiriER  UllitE 

•> 

MOVE  POSITION 

eCALLJ>ROCEDURE 

■> 

USER  MOVE  PROCEDURE 

•PASS  MESSAGE  TYPE 

•> 

11553  MESSAGE 

•DISCRIMINANT  TYPE 

-> 

DATA.WORD  COUNT  ,  0 

—  Comparator  Task 
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#COMf ARATOft  NAME  »>  CHECK  PC5JTI0K 
#CALL  PROCEDURE  •>  USER.CHECK.rROCEOURE 
*fAS$_MES$ACE_TYrE  ->  USSS.MCSSACE 
eOISCRlMlNAKT.Tm  »>  DATA .WORD .COUNT  .  0 


A*  shown  below.  the  UATL  Macro  Processor  then 
automatically  expand*  this  macro  file  into  compilable  Ada 
code  containing  the  correct  modifier/comparator  task*.  The 
macro*  are  included  in  the  Ada  code  a*  comment*. 

—  Modifier  T»»k  speciflckilon 
- —  Modifier  Task 


—  eMOoirint  name  •> 

eCAU  procedure  •> 

—  erASs  McsSACE.rvrE  •> 

—  #o:scKtMikA>n  rtTE  •> 


MOVE.MSITIOK 
U$ER_MOVEJ*ROCEOURE 
11553  MESSAGE 
DATA.NOKD.COUKT  .  0 


l«*k  type  MOVE.POS Ill ON.TYPE  is 
pr»tM  nuoamtritiortirrieei); 
entry  MCOirv  (Cum  *.  in  out  8tTS.AktiAY.rnti : 
entry  taSK.COmpletion: 
end  MOVE  POSITIONJTYPE; 
type  MOVE  rOSmOK.TYt'E. ACCESS 
is  eccess  MOVE.rosiTiOK.TYrE; 

MOVE.POStTJON  ;  M0VE.P05 ITI ON.TYPE.ACCES S : 
function  CONVERT  is  new 

UNCHECKED  CONVERSION  ( MOVE.POS IT I CN_TYPE.ACCES5 . 

UATL  MOOIFIEX  TASK  ACCESS) i 


—  Modifier  Task  body 

task  body  MOVE  POSITION  TYPE  is 
MESSAGE  ;  J1S53_MESSACE; 

function  CONVERT  is  new  CONVERT  TO  BITE  ARRAY 
(  I1SS3  MESSACE  ): 

function  CONVERT  is  new  CONVERT.D 1 SCR I M l N ATED_1 
t  DATA_NORD_COUNT  .  I1553_ME5SACE  ); 

b«*in 

loop 

select 

accept  MOOirY  (CUM:  In  out  BITE  ARRAY_PTR)  do 
MESSACE  :«  CONVERT t  CUM. all,  0  ): 

USER  MOVE  PROCEDURE  (  MESSACE  ); 

CUM. all  :■  CONVERT (  MESSACE  ); 
end  MOOirY; 
or 

accept  TASK.COMPLETION; 
exit; 

end  select: 
end  loop; 

end  MOVE_POSlTION_TYPE: 

—  Comparator  Task  specification 

—  Comparator  Task 


—  eCOMPARATOR  NAME  •> 

—  *CALL  PROCEDURE  -> 

—  ePASS  MESSACE  TYPE  -> 

—  #OISCRIMINANT  TYPE  -> 


CHECK  POSITION 
USER  CHECK  PROCEDURE 
11553  MESSACE 
DATA  WORD  COUNT  .  0 


task  type  CHECK  POSITION  TYPE  is 
prafma  PRIORlTYtPRIORITY' last) ; 
entry  COMPARE  (CUM  :  in  BYTE  ARRAY  PTR; 

MATCH  STAT:  out  UATL  MATCH  STATUS) ; 
entry  TASK  COMPLETION: 
end  CHECK  POSITIONJTYPE; 
type  CHECK  POSITION  TYPE  ACCESS 

is  access  CHECK  POSITIONJTYPE: 

CHECK_POSITION  :  CHECK_POSITION_TYPE_ACCESS; 
function  CONVERT  is  new 

UNCHECKED  CONVERSION (CHECK  POSITION  TYPE  ACCESS. 

UATL_COMPARATOR_TASK_ACCESS) ; 


—  Comparator  Task  body 

task  body  CHECK_POSITION_TYPE  is 


function  CONVERT  is  new  COXVERT.D I SCSI M I RATED. I 
t  DATA .MORD.COUNT  .  I 1553. MESSAGE  ): 

beein 

loop 

select 

accept  COMPARE 

(CUM  :  In  BYTE.ARRAY  PTR. 

MATCH  STAT  :  Out  UATL.MATClt.STATUS )  do 
USER.CHECK.PROCEOURE 

(CONVERTC  CUM. all,  0  I.  MATCH.STATI ; 
end  COMPARE; 
or 

accept  TASK, COMPLETION; 
exit; 
end  select; 
end  loop; 

end  CtlECK.POSITION.TYPS; 

The  user  then  declare*  ihe  UATL  event*  with  the*e 
constructed  task*  a*  the  modifier/comparator  ta*k*  to  be 
called.  Thu*  the  user  never  ha*  to  worry  about  the  genera! 
UATL  modificr/comparator  ta*k  form  but  only  about  the 
logic  inside  hi*  own  modifier/compsrator  procedure*. 

--  UATL  stimulus  call  usln*  the  defined  modifier 

STIMULUS  (BLOCK  *>  ’STIMULUS  CALL  BLOCK’, 

EVENT  »>  ’STIMULUS  CALL  EVENT’. 

INTP  ->  11553B, 

STIM  LIST  »>•  USERS  MESSACE, 

CIRCULATE  »  3, 

MSC  RATE  »>  2.0. 

TIME  TO  CO  »>  3.0, 

MOOiriER  ->  CONVERT (MOVE  POSITION) . 

CYCLE  ->  CYCLE  CONSTANTLY, 

TRIC.MOOE  »>  RUN) ; 

Functional  Instrument  Control  Data  Typing 


In  defining  the  instrument  control  data  t>pes  a  tradeoff  had 
to  be  made  between  strong  typing  that  would  allow  tight 
control  of  the  legal  operation*  on  the  defined  type*  and 
would  catch  more  possible  errors  at  compile  time,  and  the 
amount  of  effort  needed  to  implement  this.  While  it  i* 
desirable  to  define  all  physical  quantities  (e.g.  volts, 
amperes,  watts,  meters,  etc.)  as  separate  types  and  explicitly 
define  nil  the  allowed  operations  on  these  types,  it  becomes 
unwieldy  to  achieve  this  in  practice. 

While  the  legal  operations  for  data  types  can  be  defined,  if 
tight  control  is  to  be  achieved  it  is  necessary  to  define  all  the 
possible  operations  on  them.  This  can  be  a  daunting  task  if 
one  considers  all  the  intermediate  results  possible  in  a  very 
complex  calculation.  An  answer  to  that  might  be  to  allow  a 
general  type  like  float  to  be  the  type  of  those  intermediate 
results,  but  then  that  significantly  weakens  the  typing  for  the 
main  types  defined. 

Additionally,  although  operations  between  operands  of  the 
same  type  are  in  general  not  valid  for  physical  quantities 
(e.g.  volts  *  volts  is  undefined),  they  are  implicitly  allowed 
in  Ada.  Infix  operator  functions  that  would  hide  the  implicit 
operations  would  have  to  be  written  to  signal  some  error  (an 
exception,  perhaps)  as  part  of  their  execution  for  invalid 
operations  between  operands  of  the  same  type. 

Specific  infix  operators  would  also  have  to  be  defined  for  all 
physical  types  to  allow  their  multiplication/division  with 
unit-less  float  types.  A  further  problem  is  then  encountered 
in  the  use  of  named  numbers  since  the  context  resolution  is 
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ambiguous  when  using  numeric  literals  with  overloaded 
operator*.  The  literals  would  have  to  be  explicitly  convened 
to  un'it-ks*  float  to  avoid  ambiguity  with  conversion  to  the 
invalid,  error  producing,  operation  between  operand*  of  the 
tame  type.  The  ramifkation*  of  wrong  typing  *eemed  to 
outweigh  the  benefit*  obtained. 

The  UATL  solution  wa*  to  define  the  data  types  for  all 
physkal  unit*  a*  *ubtype<  of  the  ponable  float  type. 
Although  this  doe*  not  prevent  the  we  of  physteatly  invalid 
mathematkal  operation*  between  type*,  it  still  separate*  the 
definition*  of  all  physical  units  and  defines  them  with  the 
proper  ranges  that  are  verified  by  the  Ada  constraint 
checking.  The  u*e  of  descriptive  names  for  variables,  with 
the  phy*kal  *ubtypc  name  at  the  end,  e.g.  POWER_LEV£L_ 
DBM  also  help*  minimize  data  typing  error*. 

Rebosttog  Issue* 


The  UATL  wa*  developed  on  a  VAXwation  It  and  then 
ported  to  the  ITT  XTRA/2S6.  In  general,  Ada'*  portability 
enabkd  u*  to  reho*t  the  UATL  with  a  minimum  of  host 
processor  unique  code. 

Problems  were  encountered  with  the  MS-DOS  WOK 
memory  management  limitations.  Pan  of  the  problem  wa* 
solved  by  using  the  Alsy*  compiler  which  was  able  to  create 
executables  that  can  run  in  protected/extended  memory 
mode.  However  this  could  not  be  done  when  interfacing  with 
the  IEEE  -188  bu*  because  the  interface  driver  supplied  by 
National  Instrument*  only  operated  in  real  mode. 

The  UATL  use*  unchecked  conversion*  but  not  all 
compiler*  perform  the  conversion  in  the  same  manner. 
Problem*  were  encountered  with  the  unchecked  convention 
of  variant  record*  in  the  Meridian  2.1  compiler.  Because  the 
Meridian  compiler  store*  variant  records  a*  a  set  of  fixed 
fields  with  a  pointer  to  the  variant  ponion.  When  an 
unchecked  conversion  is  performed  the  u*er  gets  the  addre** 
of  the  variant  field  instead  of  the  actual  data  within  the  field. 
Special  conversion  package*  were  written  to  extract  the 
desired  data.  The  result*  of  an  unchecked  conversion  on  the 
Alsy*  and  DEC  compilers  do  provide  the  same  expected  data 
and  so  the  same  generic  conversion  package  can  be  used. 
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ABSTRACT 

The  Descriptive  Intermediate  Attributed  Koodoo  foe  Ada 
(DIANA)  Query  Language  (DQL)  l*  a  set  of  primitive  witch  op¬ 
erations  and  combining  operator*  (or  querying  the  DIANA  tout- 
mediate  form  o(  Ada  source  code,  nmeh  UK*  a  conventional  Infor¬ 
mation  system  dau  haw  can  be  queried.  DOL  can  be  toed  by  an 
anal  pc  to  determine  how  well  the  Ada  softwar  e  conform!  to  design 
standards,  to  compote  metric*  bawd  on  the  software's  structure, 
and  to  brow*  through  the  toftware.  OQL  can  abo  be  used  a*  an 
Integration  layer  on  whkh  new  and  existing  tools  may  be  Imple¬ 
mented  to  extract  relevant  Information  about  Ada  source  code. 
DQL  i*  being  Implemented  on  a  network  of  Son  3"  workstations  at 
an  Electronics  System*  Division  (ESO)  Acquiskion  Support  Envf- 
ronment  (EASE)  utUky  win*  a  bit-mapped,  windowed  user  Inter¬ 
face  and  a  server-bated  DIANA  tree  manager  to  allow  Interactive 
analysis  of  tlte  Ada  source. 


I  INTRODUCTION  TO  THE  DIANA  QUERY 
LANGUAGE 


M  DIANA 

The  Descriptive  Intermediate  Attributed  Notation  for  Ada 
(DIANA)  It  a  public  standard  (EvanS3)  for  defining  a  tree 
structure  that  captures  all  the  semantic  Information  In  Ada  source 
code.  Semantic  tree  structures  such  at  DIANA  are  often 
produced  by  the  front  end  of  a  compiler,  allowin*  different 
compiler  back  ends  to  be  customised  for  a  particular  target 
computer.  In  DIANA'S  case  the  trees  become  the  mechanism  by 
which  the  Ada  compiler  "browses"  the  source  code  during 
activities  such  at  code  feneration.  The  creators  of  DIANA 
recognised  that  such  an  Intermediate  form  would  be  useful  to  tools 
other  than  the  compiler.  The  DIANA  standard  is  an  attempt  to 
encourafc  compiler  writers  to  generate  Information  that  could  be 
used  by  tool  developers. 

1.1  THE  DIANA  QUERY  LANGUAGE 

The  DIANA  Query  Language  (DQL)  and  iu  associated  tools 
are  a  mechanism  to  analyse  Ada  source  code  (or  Ada  used  as  a 
Program  Design  Language)  by  searching  through  the  Ada  source 
for  language  constructs  of  Interest.  Using  an  Ada  intermediate 
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form  such  as  DIANA  eliminate*  the  need  for  these  analysis  tools  to 
parse  and  check  for  semantic  correctness;  tools  that  build  DIANA 
trees  perform  this  function.  DQL  and  ks  toots  allow  the  querying 
of  DIANA  trees  bated  on  Ada  language  constructs.  DQL  does  not 
require  familiarity  with  DIANA  and  ks  model  of  connected  nodes 
and  classes;  k  merely  requires  famlUarky  with  the  Ada  language 
and  ks  constructs  at  defined  kt  the  Ada  Language  Reference  .Man¬ 
ual  (DODI3). 


2  PROBLEMS  BEING  ADDRESSED  BY  DQL 


1.1  ANALYSIS  OT  SOFTWARE  WRITTEN  IN  ADA 

An  important  step  In  the  analysis  of  Ada  software  systems  h 
the  checking  of  that  software  against  erkeria  that  define  the  re¬ 
quirements  for  the  reliability,  maintainability,  and  other  aspects  of 
the  system.  The  Ada  language  standard  (MIL-STD-JS13A)  and 
compilers  validated  against  that  standard  provide  automatic  check¬ 
ing  (such  as  strong  type  checking)  not  found  In  earlier  languages. 
Rut.  there  It  a  need  for  analysis  capabitii'es  that  are  outside  the 
Ada  standard  and  the  compiler. 

Each  Ada  application  program  it  subject  to  kt  own  set  of 
criteria  that  defines  the  standards  for  how  well  wrkten  the  software 
Is.  A  development  organisation's  protect  management  approach, 
the  software  design  methodology,  the  particular  application's 
needs,  and  the  preferences  of  the  developers  all  combine  to  define 
these  erkeria.  Some  erkeria  can  be  expressed  at  cxplickly  defined 
design  and  coding  rules:  others  arc  heuristics  hated  on  previous 
experience.  Checking  any  large  collection  of  software  against  a 
variety  of  rules  is  diffkuk.  especially  given  the  limited  amount  of 
time  generally  allocated  to  quality  analysis.  Automated  support  for 
such  checking  is  needed,  and  fortunately  k  Is  possible  because 
Ada's  notations  allow  more  of  the  Information  about  the  software 
to  be  captured. 

1.1  CHECKING  CONFORMANCE  TO  DESIGN  RULES 

Many  application  areas  and  design  methods  havr  formally 
defined  design  rules  that  can  be  mechanically  applied  to  software. 
Examples  include  the  Normal  Form  rules  for  data  bases  (DateH), 
the  starvation  and  deadlock  guidelines  for  communicating  sequen¬ 
tial  processes  (KoarS5).  and  the  equivalency  rules  for  data  flow 
decompositions  (WardSS).  Some  of  these  design  rules  arc  very 
specific  to  Ada,  such  as  exceptions  not  outliving  their  names  or 
"erroneous"  assumptions  (Soft 8 2).  These  design  rules  involve 
checking  the  Ada  code  against  itself  and  against  other  develop¬ 
ment  products,  such  as  a  requirements  specification. 
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The  process  of  defining  alt  the  design  rule*  (comini  (com  sev¬ 
eral  different  ate*t)  »i » hey  10  Ad*  tt  *  m*)oe  activity.  Ap¬ 

plying  all  thru  design  rule *  10  the  Ad*  «« ce  code  K  »luj  a  major 
actwky.  ItotM  of  (ho  Import  »ncr  o(  then  rule*  in  determining 
overall  software  quality. »  Urge  software  development  erganUation, 
may  «M  *n  independent  Software  Quality  Assurance  (SQA)  pour 
io  ensure  these  rule*  in  affiled  before  the  software  k  release*! 
Manual  application  of  design  rule*  to  software  e»n  hr  tedious 
(«m<<  much  of  k  is  mechanical),  so  automated  support  »ooW  »td 
SOA  In  k*  twk. 

DQL  allow*  design  ruin  to  hr  formally  stated  it  »  DQL 
query.  These  ruWi  c*n  represent  generally  pood  software  engi¬ 
neering  practice*.  or  they  c»n  hr  specific  to  an  application  domain. 
These  queries  can  then  hr  applied  to  thr  software  to  find  thorr 
Ad*  codr  mo lonr  that  conform  to  or  violate  these  design  rule*. 

1.)  BROWSING  THROUGH  ADA  SOFTWARE 

In  addition  to  analysis  with  rerpect  to  thr  formally  defined 
design  rule#,  Ad*  software  i*  subject  to  heuristic  analyst*.  Thu 
heuristic  analytic  U  frequently  applied  by  having  someone  read  thr 
Ad*  »oft«*rt.  looking  lor  c«rt*ln  characteristic*  or  pattern.  ThU 
can  br  difficult  to  do.  since  to  a  weH-modolarlred  Ad*  system  thr 
information  needed  may  br  spread  throughout  many  More*  filet, 
and  in  sevetal  piace*  within  a  given  source  We.  The  analyst  will 
want  to  'browse*  triotM  specification*  and  hodiet,  parent  and 
subunk*,  tatter*  and  calieee,  type  declaration*  and  uses,  etc.  Try- 
in|  to  broaoc  manually  throu*h  a  large  Ada  system  can  he  difficult, 
time  consuming.  and  error  prone. 

Browsing  in  Ada  U  further  complicated  by  overloaded  name*, 
KOpe  and  vUlbllity  rule*,  and  renaming  declaration*.  Browsing 
require*  looking  at  the  semantic  meaninc  of  an  identifier,  not  lux 
ki  syntactic  appearance  in  the  source  code,  without  temantic- 
baied  browsing,  accurately  readlni  Ada  source  code  can  be  ledl- 
out.  DOL  allow*  romantic  browsing  by  allowing  an  analyst  to  fol¬ 
low  the  connection*  between  Ad*  source  construct*  (by  'walking* 
the  awociated  DIANA  tree). 

14  PORTABILITY  OF  ANALYSIS  ACROSS  HOST  SYSTEMS 

Since  the  Ada  lart|ua|e  wat  designed  to  maximUe  portability 
aero**  environment*,  the  formal  and  heuriitic  detipt  rule*  that  can 
be  applied  to  Ada  must  alto  be  portable.  There  exiM  tome  formal 
rule  checker*  (tuch  a*  set/uiage  analyser*)  and  leatual  browsers 
(luch  a*  re  pilar  expression  searcher*)  that  can  be  uteful  for  Ad*. 
but  many  of  the*e  are  ipecifie  to  a  particular  ho*t  environment  or  a 
specific  Adc  Programming  Support  Environment  (AFSE).  Proper 
application  of  detipt  rule*  may  involve  comparative  analy*it  of 
Ada  io  ft  ware  residing  on  different  APSE*  for  rtusabilky  or 
interface  check*).  Analytic  would  like  to  do  their  work  without 
havin|  to  leant  the  individual  Ada  source  code  browsing  proce¬ 
dure*  of  teveral  different  ho*u  or  APSE*. 

DQL  provides  an  abstract  Interface  to  the  DIANA  Intermedi¬ 
ate  forms  that  can  be  created  by  a  variety  of  bon  environments 
and  APSEs.  The  same  DQL  query  and  desipt  rule  checkin*  can 
be  used  across  different  DIANA  Implementations.  DQL  and  Its 
took  also  allow  queries  that  span  DIANA  trees  so  the  Ada  con¬ 
structs  in  two  different  APSEs  and/or  hotu  can  be  checked. 


IS  ACCESS  TO  SOFTWARE  OVER  A  NETWORK 

The  community  of  software  engineer*  wishing  to  analyse  a 
ucular  piece  of  Ada  software  may  be  targe.  In  addition  to 
V.QA.  tndivtdu*!  propammer*.  malntalner*.  and  man apt*  win 
want  to  apply  design  rule*  and  bto«se  the  code.  Ad*  propammer* 
make  heavy  u*e  of  an  Ad*  compiler  a*  a  quick  measure  of  code 
that  wat  Jux  written.  When  available,  automated  delipi  rule 
checker*  used  by  progr*mm»r*.  manager*,  and  SQA  wilt  abo  be¬ 
come  frequently  u*ed  took.  Tbk  w«  Introduce  the  uwal  problem* 
of  muklpie  Kcttf  Kro**  a  network,  and  maintaining  corwixertcy 
among  software  stored  at  several  different  location*.  Programmers 
browsing  through  Ada  code  would  hke  the  transitions  between  We* 
and  networks  to  be  a*  smooth  a*  possible. 

The  DQL  tool  set  sep*r»te*  the  activity  of  Searching  (Urge) 
DIANA  trees  with  a  DQL  query  from  the  display  of  any  re*uks 
from  that  query.  The  Urge  amount  of  work  associated  with  man¬ 
aging  DIANA  tree*  k  isolated  In  a  few  DIANA  tree  Server*,  which 
arc  accessed  by  user*  at  workstation*  on  a  local  area  network. 
DIANA  tree  server*  allow  user*  to  abate  query  re*uk*  without  forc¬ 
ing  each  user  to  recompute  each  DQL  query  on  their  own  worksta¬ 
tion. 


3  SIMILAR  WORK  ADDRESSING  THE  PROBLEM 
OF  ADA  ANALYSIS 


3.1  EXISTING  DIANA  ACCESS  METHODS 

Mom  Ad*  compilers  that  use  an  Intermediate  form  like  DI¬ 
ANA  (or  something  similar  to  h)  have  defined  a  method  tor  ac¬ 
cessing  node*  in  the  ute.  Unfortunately  mow  compiler  vendor* 
treat  these  access  method*  as  proprietary,  preventing  other  pro- 
paint.  such  as  analysk  took,  from  taking  advantage  of  the  DIANA 
ueel.  A  few  vendor*  allow  partial  acre**  method*,  tuch  a*  the 
Intermetric*  Program  Library  Acer**  Package  (PLAP)  (Gord|3) 
and  the  Rational*  Design  Facility  (Bachl?),  but  these  are  oriented 
toward  offline  report  generation  and  not  online  browsing.  Some 
DIANA  acccM  k  provided  on  Rational**  RIOOO*  environment,  but 
there  k  no  vendor-independent  DIANA  tool. 

3.2  EXISTING  ADA  ANALYSIS  TOOLS 

Current  APSEs  may  contain  took  ih*t  provide  some  informa¬ 
tion  useful  to  an  analyM.  Some  documentation  tools  such  at 
Byron*  (OordlJ)  and  the  Ada-based  Design  And  Documentation 
Language  (ADADL)  provide  Government  standard  deliverables 
and  reference  reports  that  have  some  use.  but  these  are  batch  ori¬ 
ented,  and  k  k  difficuk  to  correUtc  multiple  batch-generated  re¬ 
ports  together  while  checking  the  satisfaction  of  a  design  rule. 
Other  tools  allow  the  computation  of  complcxky  measures  and 
other  metrics  (PerkS7),  but  often  these  metrics  are  hard-coded  to 
a  partlcuUr  formuU  and  thus  difficuk  to  customlte  to  a  specific 
application's  needs. 


•  Rational  an*  RIOOO  are  UaStanaiks  «t  Rational,  Im. 
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J.J  EXISTING  ADA  DESIGN  RULES 

The  Ada  tkeratore  comaim  many  examples  of  devign  rules. 
Ade-cpecific  design  methodolofiei  rush  >t  lulu's  Sy*»m  Design 
with  Ada  (»uht|4)  ?,rvd  Chatty 's  Process  A  b-<  taction  Mtthed  for 
Embedded  Large  Applications  (PAMELA)  (Cbetli),  define  for¬ 
mal  and  heorlxic  rule*  to  be  applet)  by  the  designer.  Other  work 
(SUM  4)  defines  rule!  that  »<  new  to  Adi  Of  are  modification!  10 
tradktenal  rules.  The  underlying  methodology  necessary  io  Nip¬ 
pon  Adi  analysis  K  In  pU<«;  what  H  needed  is  ih«  technology  io 
do  k. 


4  SIMILAR  TECHNOLOGY  FROM  OTHER  FIELDS 


4.1  RELATIONAL  INFORMATION  SYSTEMS  DATA  RASES 

The  problems  ol  supporting  aJ  V’c  data  base  searches,  new 
types  of  reports,  and  cbecki  on  tUu  Nam  correctness  are  not  new 
to  the  Information  systems  communky.  They  have  developed  data 
base  forms  sue H  »*  relational  data  Hjks  (Date*:).  Entky 
Relationship  Attribute  (ERA)  models  (Chenlt),  »ikI  semantic 
4m*  networks  (Mammll)  io  structure  their  data  In  a  way  io 
Nippon  a  variety  o(  data  k»u  roethodt  and  rtponi.  vk*kh  the 
typ*!  o(  rtponi  supported  purposely  leh  open-ended.  a  data  bate 
analyx  can  create  w»y*  to  March  foe  a  variety  of  Information 
pattern  that  pvt  new  Insight  about  sort*  enterprise. 

4.1  RELATIONAL  ALCERRA 

Data  bale  analytic  art  aided  by  a  xandard  let  of  mathemati¬ 
cal  method!  that  define  what  the  attribute!  of  the  data  bale  arc. 
and  how  thote  attribute!  can  be  queried  and  combined.  Foe  rela¬ 
tional  data  baiei.  a  relational  algebra  hat  been  defined  that  de¬ 
scribe!  how  queries  can  be  formed,  combined,  netted,  and  HOfed. 
From  the  let  of  low-level  operation!  provided  by  the  relational 
algebra,  an  analyx  can  build  a  query  that  return!  lomc  aspect  of 
the  data  bare. 

4.1  STRUCTURED  QUERY  LANGUAGE  (SQL) 

For  relational  data  bate!,  a  standard  metliod  hat  been  cre¬ 
ated  to  allow  application!  program!  to  query  a  data  bare  using  a 
relational  algebra.  The  Structured  Quay  Language  (SOL) 
(Datcll)  i!  a  standard  that  define!  the  data  type!  and  the  opera¬ 
tor!  that  implement  the  algebra.  If  a  data  bate  analyst  can  create  a 
query  In  the  relational  algebra  that  check!  some  rule,  then  an  ap¬ 
plication!  program  that  automatically  perform!  the  rule  check  can 
be  written. 


4.4  ARSTRACTING  IMPLEMENTATION  DETAILS  AWAY 
FROM  THE  USER 

One  goal  of  a  data  base  query  language  It  to  abstract  away  the 
Implementation  details  of  the  underlying  data  base.  Queries  can 
be  formed  directly  from  the  algebra  (as  In  the  natural  language 
query  forms),  oc  from  applications  programs  (such  as  those  using 
SQL)  without  regard  for  how  the  data  is  stored  on  a  disk  or  how  ft 
Is  distributed  around  a  network.  Ada  analysts  working  with  source 
code  would  similarly  like  to  browse  without  regard  for  directories, 
file  positions,  and  network  paths. 


4.$  SYNTHESIZER  GENERATOR 

The  Synthesiaer  Generator  (Repel!)  provide!  a  Semantic 
data  base  that  Is  Integrated  whh  a  source  code  edging  system  foe  a 
variety  of  computer  languages.  The  SynthesUer  Generator  doe! 
not  Separate  the  functions  of  creating  the  software  from  analysing 
the  software  for  semantic  correctness;  this  make!  k  a  useful  tool 
during  source  code  creation  and  editing.  This  integration  of  edk- 
mg  and  analysis  Is  very  tight,  making  k  ditfkuk  to  perform  )ux  the 
analysis  functions  without  working  through  the  editor  at  welt. 


5  DQl,  IMPLEMENTATION  APPROACH 

S.l  DIANA  TREES  AS  DATA  RASES 

DQL  allow!  Ada  source  code  (through  k!  underlying  DIANA 
trees)  io  be  treated  bke  a  data  base  by  defining  a  query  language 
that  operate!  on  that  data  bate.  DQL  bat  an  advantage  over  query 
language!  for  information  system!  data  bases  In  that  the  dau  deli¬ 
nk  ton  language  for  Ada  (DIANA)  is  a  (Ned  standard,  so  there  k 
Iktle  need  to  support  User-defined  data  base  schemas,  DQL  could 
be  emended  to  handle  wetl-defintd  extensions  to  DIANA  such  as 
the  structured  Ada  comments  used  by  ANNA  (Luck|!)  and  Ryron 
(OordlJ). 

S.l  INTERACTIVE  QUERY  AND  RESPONSE 

The  DQL  implementation  under  development  at  MITRE  k 
designed  to  provide  (almost)  immediate  response  to  an  Ada  ana¬ 
lyst's  query.  On-line  browsing  of  Ada  source  requires  that  the 
user  not  be  frustrated  by  long  delays  before  an  answer,  otherwise  a 
train  of  thought  may  get  lost.  If  the  cox  (in  response  lime)  for 
applying  design  rules  k  small,  an  Ad*  programmer  will  be  encour¬ 
aged  to  apply  these  rules  frequently  and  as  a  resuk,  problems  win 
be  caught  closer  to  the  time  when  they  are  created. 

S.l  EXAMPLES  OF  QUERIES 

A  DQL  query  It  bulk  up  from  approximately  ISO  primitive 
queries  (one  for  each  major  type  of  DIANA  node  and  attribute 
representing  Ada  source).  In  the  examples  below,  bold  Indicates  a 
reserved  DQL  keyword  or  character  and  Italics  indicates  a 
placeholder  for  an  Identifier  or  a  query.  A  primitive  query  k  of 
the  form 

starch  ptlmltlttjfpttmar  target: 

—  DQL  has  Ada-styk  comments 

whete  starch  names  the  entities  to  search  for,  rargrr  defines  where 
to  find  entities,  and  ptlmlilvt_cptrator  defines  the  type  of  entity 
(DIANA  node  type)  to  search  for.  Starch  »nd  torgrr  can  be 
character  strings  (to  march  Ada  Identifiers),  tlx  keyword  all  (to 
maieh  anything),  source  file  ranges,  named  DIANA  nodes,  named 
results,  or  another  subquery  wIiom  results  become  the  operand. 
For  example,  the  following  query 

all  exceplions.ralsedjn  <DIANA  notlt>; 

—  noJt  identifies  specific  place 

would  return  tlx  DIANA  node  names  which  uniquely  Identify  tlx 
name  of  any  exception  which  Is  raised  In  the  given  DIANA  notit  or 
in  any  node  tliat  is  enclosed  within  that  node*!  scope.  A  nested 
query  would  look  like 
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(rear tk  e fttwl  urget)  cfttmofl  larger; 

where  the  query  within  the  pertrahevH  it  called  a  *u bqoery.  An 
exsmpl*  of  iHb  ta 

(•41  ext»ptUw«_deflwd_la  <**fe  2>) 
except  i««*,ral**<l_l*  <DIASA  *frl<  />: 

—  query  spanning  two  Km* 

whKh  would  again  return  exception*  raised  In  the  scope  of  node  /. 
but  here  only  (box  exception*  that  art  d< (Intel  In  the  scope  of 
*eJt  3  would  be  returned  Tbt  sobquery  act*  a<  a  qualifier  10  th« 
ware*  operand  of  the  outer  query.  A  fflmhhtmer<t*ttr  H  on*  of 
the  350  reserved  xtyword  queries  such  at  *bjt<l_dtfl*td_l«, 
a<c.M_i>pt_of  and  *"iry_<all*_ta, 

In  addition  to  tbt  subquery  construct.  DOL  queries  tan  bt 
combined  by  using  usury  and  binary  operator*  Tbt  unary 
operator*  art  applied  with  ottry.Ofrntfor  (  furry  )•  The  at  ten 
unary  operator*  Include  unit*,  which  remove*  duplicate  node*,  and 
only,  which  limit*  tbt  Matching  of  a  scops  to  only  iu  topmost 
level  For  example,  the  query 

uatq  (alt  aebpro*rai«_t»H»J«  <OlASA  pk>J<»; 

would  return  tbt  node*  that  identify  a  cal*  to  any  subprogram.  but 
any  duplicate  reaub*  that  called  the  tame  subprogram  would  be 
eliminated  by  unlq,  The  binary  operator*  are  applied  with  (parry 
iMary_i'prruror  parry).  The  tit  binary  operator*  include  union, 
which  Join*  the  reaub*  of  two  queries,  and  dlff,  which  remove* 
retuStt  proem  on  both  the  left  and  right  side*.  For  example,  the 
query 

((•II  »ubpeo«raan_addr*M  tronrer  rnnyra)  unlnn 
(all  eniry.oddmt  ooarcr  ranges)); 

will  return  the  node*  that  Identify  any  place  in  the  given  wa ere 
range  where  the  'ADDRESS  attribute  I*  referenced  for  Cblter  a 
Subprogram  or  a  taab  entry. 

Both  query  rewk*  and  cursor*  (*ymbolic  name*  for  a  given 
DIANA  node)  can  be  named  In  the  form 

retail  :■  parry;  ea nor  :■  <DIASA  nodes; 

—  reauh  k  cursor  definition 

with  later  queries  able  to  ust  those  names.  Query  names  (that  act 
at  macros)  are  defined  In  the  form 

name  Is  parry;  —  query  name  definition 

where  current  position*  are  used  to  replace  placeholder*  In  parry. 
Ouencs  are  strongly  typed  so  the  user  I*  warned  when  semantic 
DOL  error*  are  made.  In  addition  to  searching  for  nodes,  the 
count  unary  operator  and  the  four  standard  mathematical  fune- 
Hurt*  (binary  operator*  ♦,  *.  /)  can  be  used  to  compute  metrics. 

!.*  INTERMEDIATE  RESULTS  AS  STREAMS 

Each  query  (including  each  subquery  wliliin  a  higher  level 
query )  produces  a  stream  of  result*.  These  streams  can  be  built 
and  combined  dynamically.  Any  additional  connections  needed 


when  crossing  Ada  bbrary  and  source  directory  boundaries  are 
transparent  to  the  user.  At  the  top-most  level  the  query  returns  a 
stream  o(  DIANA  node*  (including  source  positions),  so  other 
software  development  environment  tool*  can  scroti  editors,  high* 
light  text,  or  Just  Ust  resub*  a*  needed. 

*.*  SERVER  ARCHITECTURE  TO  FROMOTC  PORTABILITY 

DIANA  tree*  are  handled  within  OQL  servers,  whh  a  central- 
ised  dau  base  beeping  track  of  which  trees  are  handled  by  which 
server.  When  a  query  cause*  DIANA  tree  boundaries  w  be 
crossed,  this  may  resub  In  hmt  processor  boundaries  being  crosaed 
as  well,  These  different  htwt  processors  may  be  different  comput¬ 
er*,  running  different  operating  system*,  and  so  have  different  ver¬ 
sions  of  the  DOL  server.  DQL  supports  portability  by  swing  a  stan¬ 
dard  Remote  Procedure  Can  (RPC)  Interface  that  allow*  queries 
(and  resub  streams)  to  cross  arbitrary  host  boundaries. 


<  IMPLEMENTATION  CONCERNS 


(.1  SIZE  OF  DIANA  TREES 

Our  DOL  Implementation  uses  the  Intermetrics  Ada  Compi¬ 
lation  System  (ACS)  front  end  (Imeti)  at  the  source  of  semanti¬ 
cally  complete  DIANA  tree*.  LUte  most  complete  DIANA  Wees, 
'be  ACS's  intermediate  form  has  a  very  large  expansion  factor  (up 
10  20:1)  from  the  original  Ada  source.  Such  large  tree*  are  time 
consuming  to  create  and  too  large  to  allow  «*ch  user  to  Have  his/ 
her  own  copy.  The  motivation  for  having  DQL  server*  wa»  to  al¬ 
low  these  tree*  to  be  created  once  and  then  shared  among  ad  us¬ 
er*.  Figure  I  below  show*  a  Ruhr  notation  example  of  a  query  that 
wa*  Initially  handled  by  Tree  Server  *1  running  In  Server  *1.  but 
eventually  Involved  other  Tree  Server*  (*2  and  *)).  tunning  on 
another  server,  bt  the  computation  of  the  resubs  for  the  user  at 
Worbstatlon  #1. 


<.2  DQL  QUERIES  CAN  RE  VERBOSE 

A  DQL  query  that  check*  for  a  particular  design  rule  can 
become  very  complex.  Involving  many  subqueries.  Just  a*  Infor¬ 
mation  system*  user*  have  trouble  Instantly  creating  semantically 
correct  SQL  queries.  Ada  analyst*  may  have  trouble  creating  com¬ 
plex  DQL  queries  by  Just  typing  them  In  by  hand.  A  menulng 
system  that  provides  an  analyst  with  some  guidance  it  being  devel¬ 
oped.  DQL  also  allow*  Individual  queries  to  be  stored  by  name; 
this  allows  a  complex  query  to  be  bulk  up  gradually  from  ks  com¬ 
ponent*  and  to  be  reused  easily. 

«.3  BROWSING  THROUGH  INTERMEDIATE  RESULTS 

Once  tlie  query  results  have  b«n  computed,  the  analyst  will 
wish  lo  browse  through  them  and  the  source  code  Oat  they  repre¬ 
sent.  The  applications  program  that  captures  tlte  highest  level  re¬ 
sult  stream  am)  display*  it  on  a  workstation  screen  Is  integrated 
Into  EASE,  an  Ada  analysis  environment  (ByrnSS)  running  on  Sun 
3  workstations  that  allow*  multiple  window*  of  Information  to  be 
created  and  managed.  The  DQL  programs  become  Just  another 
type  of  analysis  tool  supported  by  EASE. 
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Figure  1  show* a  DQL  Query  Result*  task  (progra m)  that  wilt 
display  wulu  (as  ASCII  lew)  a*  they ate  teceWed  from  %h«  Serv¬ 
er.  The  user  can  start  twing  Omm  resuk*  a*  soon  a*  they  »«« 
received;  there  H  no  need  io  for  the  got ry  w  Im  completed. 

The  umt  could  request  »« editor  (starting  at  the  line  containing  a 
particular  node)  or  start  a  new  query  based  on  *  particular  result 
or  *n  entire  Mfesm  (wing  kudt  umret  or  rocgcr). 

g.4  CONCURRENT  ACCESS  »V  MULTIPLE  USERS 

Severs!  different  umm  may  wish  10  analyse  the  Mme  DIANA 
tree at the  Mint  time.  Forcing  mm  of  them  to  wait  until  an  ear- 
Utf  umt  has  finished  win*  (he  tree  would  Introduce  unacceptable 
response  tlmt  delays.  Tbe  DQL  server  impiementauon  me*  dr 
ntmka»y  croud  Ada  task*  to  do  each  o(  tbe  subgoertes.  Figure 
2  below  »how*  bow  an  example  query  Ut  a  Mfvtf  might  connect  k» 
subqueries,  “Dm  concentrator*  combine  tndhidua)  subgueries  into 
a  single  stream  o(  resuk*.  Another  user's  query  would  Introduce 
new  task*.  but  tht  Mtvtr  would  allow  all  of  tbtm  to  run  concur* 
rtntly. 

Not*  that  tht  conntctMty  bttwttn  resuk  stream*  U  done  al* 
mo*  totally  within  a  DIANA  tr*t  Server.  Mom  ntw  queries  will  bt 
refinement*  of  previous  re*uk*:  dynamically  added  queries  can 
rtUM  existing  subquerle*  and  rtMilM.  Potentially  taptnilvt  net¬ 


work  trawler*  of  rtsuk*  to  a  workstation  art  don*  only  when  tht 
user  explicitly  request*  them  with  tht  tmaty  display  (gurry)  func¬ 
tion.  Tht  workstation  can  bt  dedicated  to  the  user  Inter  fact,  while 
the  server's  hardware  can  b«  at  powerful  as  necessary  to  act  as  a 
DIANA  data  bau  machine. 

«.*  MANAGEMENT  OF  EARLIER  QUERV  RESULTS  AND 
DEFINITIONS 

At  an  analyst  uses  DQL.  many  query  definitions,  cursor 
names,  and  query  results  may  be  created.  In  addition,  predefined 
gutty  dcfUtklont  and  resoks  (capturing  an  organisation'*  standard 
design  rules)  may  be  used.  To  manage  all  this  information,  special 
EASE  status  window*  (on  the  user's  workstation  screen)  ate  up¬ 
dated  as  new  DQL  resukt  arc  created. 

Figure  I  show*  Out  ties  and  Resuhs  tasks  running  In  a  work* 
Station;  as  each  new  query  it  defined  or  retuk  It  reguested,  these 
window*  arc  updated.  EASE  allow*  the  user  to  browse  through  the 
window*  holding  query  resukt  with  standard  mouse  pointer*  and 
pop-up  menu*.  EASE  maintain*  connection*  between  window*, 
so  a  user  can  issue  command*  to  one  window  by  running  a  com¬ 
mand  in  another  window. 
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<.<  CACMEING  OF  INTERMEDIATE  RESULTS 

■n*  intermediate  results  of  a  subquery  (both  nMwd  and  un- 
natMd)  may  be  tlx  same  results  needed  for  tom*  bur  query.  pot- 
»ibly  for  another  u»«r.  Figure  2  shows  bow  to me  results  can  be 
S!P  independent  query  result  colbctions  foe  bur  reuse. 

h  U'*.r  (tub)'l'*ry  u  Utu*d  «hat  matches  an  existing  r«iuh 
collection,  ihai  coUactlon  can  b«  read  instead  of  recreated.  Note 
that  more  than  one  query  can  read  from  a  coUactlon  at  the  tame 
time  to  increase  concurrency. 


7  CURRENT  LIMITATIONS 


7.1  DIANA  TREES  MUST  RE  STATIC 

The  DIANA  tree*  that  DQL  works  with  mutt  be  semantically 
correct  Ada  and  they  may  not  change  while  the  treat  are  bain* 
analyted.  Partially  correct  treat  are  not  uiable.  While  thlt  limita¬ 
tion  doet  not  affect  a  uter  that  analyiet  the  Ada  source  only  after 
hhas  been  rebated  by  the  protrammers.  Ada  developers  may  find 
DQL  hard  to  use  while  writini  code. 


7.1  DIANA  STANDARD  IN  FLUX 

The  DIANA  trees  wed  by  DQL  are  those  bulk  by  the  ACS. 
which  wet  a  variant  of  the  1913  DIANA  standard.  Since  the 
ori|inal  DIANA  definition,  there  have  been  other  DIANA  stan¬ 
dards  proposed.  In  addition,  each  Ada  compibr  vendor  hat 
added  ks  own  extensions  and  modifications  to  DtANA.  making 
truly  portable  DIAN'A-based  tools  difficult  to  develop.  We  have 
tried  to  abstract  the  DQL  primitive  queries  from  the  details  cf  a 
particular  DIANA  impb mentation,  but  there  is  no  guararste  that 
DQL  wiU  cover  every  vendor's  intermediate  DIANA-ltk !  form. 

7.3  EXTENSIONS  TO  DIANA 

In  addition  to  the  compiler-specific  variations  in  DIANA  Im¬ 
plementations,  some  Ada  tool  developers  have  greatly  extended 
the  amount  of  information  that  is  captured  in  an  intermediate  form 
through  Ada  language  extensions.  Examples  include  the  struc¬ 
tured  comment  conventions  used  for  project  management  informa¬ 
tion  (at  in  lyron  and  ADADL)  or  formal  specification  (at  in 
ANNA  (Luckta)  and  TSL  (LuckS7)).  To  help  with  the  analysis 
of  Ada  software  using  these  notations,  both  the  DIANA  tree  serv¬ 
ers  and  tlte  DQL  Unguagc  would  have  to  be  extended  with  addi¬ 
tional  primitive  queries. 
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7.4  PORTABILITY  TO  OTHER  WORKSTATION 
ENVIRONMENTS 

The  current  DQL  (»ml  EASE)  Implementation  run*  on  Sun 
workstation*  using  the  Sun  VhuaUlmegrated  ftirtwumtu  for 
Wotkswion*  (SimVtKW*).  Bixh  EASE  and  DOL  would  be  avail¬ 
able  to  *  btoadet  <Uw  of  t*xf  >f  they  f*n  under  *  workstation 
i‘iiiff8WMW  l Km  mu  mi  Industry  standard-  B«h  iK«  W 

ani  Son  Network  extensible  Windowing  System  (SunNeW$«)  en¬ 
vironment*  muU  be  possible  How*  fee  future  \tfswmt  of  ih«  »«K- 
station  Interface  web. 


I  FUTURE  WORK 


1.1  CURRENT  STATUS 

DQL  I*  being  implemented  in  phase*  The  initial  phase  con¬ 
sisted  of  three  parts: »  scheming  of  ihe  ACS  front  end  10  Son  Serv¬ 
er*  a*  *  ieuece  for  DIANA  trees;  creating  *  DOE  query  language 
pr«ce*»or  iKm  convert*  >  query  (m  ASCII  Km)  kwe  a  >emar>tkttty 
correct  Kt  of  call*  m  a  DIANA  tree  Server:  and  implementing  a 
DIANA  tree  (rmt  for  ih<  creation  and  management  of  subquerk* 
and  Intermediate  re*uh*.  later  phase*  wi|t  pr mid*  a  •  jenuing  ip- 
i«m  for  the  creation  of  quetle*  Mid  foil  support  of  quetle*  »hkh 
crow  niw  boundMie*.  Each  phase  win  also  provide  standard 
queries » Km  Ada  analyst*  can  ok  at  an  inirodoetton  to  browsing 
through  Ada  soflwxte. 

1.1  DQL  AS  A  LAYER  FOR  FUTURE  TOOLS 

The  EASE  envltoewnen*  K  intended  a*  a  layer  on  which  took 
n»ch  a*  DQL  could  be  bulk.  DQL*»  tool*  provide*  a  vatwty  of 
interface*  that  other  tool*  can  w*e  to  provide  their  Ada  Informa* 
tion  Example*  of  the*e  Interface*  Include  the  DIANA  tree  *erv» 
eri.  the  DQL  query  pa neri,  and  the  jcrollable  DQL  query  result 
window*. 

An  example  of  a  tool  that  could  u*e  DQL  I*  an  expen  tyitem 
that  need*  Information  about  Ada  source  to  populate  it*  knowledge 
Kate.  Sometime*  proper  checking  of  a  design  rule  may  involve 
complex  forward  chaining  rule*  or  complicated  pattern  rtcogni* 
tion.  Such  design  rule*  could  be  captured  In  an  expert  lyatem, 
with  RFC  call*  to  DIANA  server*  u*<d  a*  part  of  the  infetencing 
mechanism. 

».J  CONVERSIONS  OF  EXISTING  TOOLS 

Existing  tool*  uitl  be  modified  to  take  advantage  of  live  infor¬ 
mation  that  can  be  provided  by  DQL  queries.  For  example,  the 
CArleton  Embtded  system  Design  Environment  (CAEDE)  Bultr 
diagram  editing  toot*  (BuhrSfi),  running  on  Sun  workstations, 
could  be  modified  so  diagrams  could  be  created  from  Ada  source 
code  as  well  as  CAEDE  currently  creates  die  source  code  from  die 
Bultr  diagrams.  This  would  be  done  by  querying  to  determine  li¬ 
brary  units  and  die  tasks  within  them,  and  then  seeing  how  the 
unKs  call  each  other.  Such  modified  tools  would  allow  the  Ada 
source's  design  to  be  presented  in  a  form  (such  as  tlx  Buhr  n ora¬ 
tion)  that  Is  familiar  to  a  particular  analyst. 
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ADA  PORTABILITY  AMONG  HKTINOGINBOUS  SYSTKNS 


NASSIR  BAZZ1  and  BIN JAM IN  CASAW) 


Advanced  Software  Technology,  C1COM 


AMTRACT 

Hset  government  contracts  arc  developed 
by  many  contractors  who  often  utilise  their 
resources  to  perform  their  assigned  task. 
Compatibility  becomes  a  problem  at  the  tine 
of  integration  if  different  resources  have 
been  used.  Therefore,  engineers,  or  poasibly 
consultants,  scat  I'e  utilised  to  solve  the 
incompatibility  problem.  This  process  is  net 
enly  inefficient  but  often  costly  to  both  the 
company  sod  the  government  in  terns  of  money 
and  tine. 

Designing  an  Ada  utility  package,  which 
is  Independent  of  the  operating  system,  is  a 
feasible  solution  to  the  portability  problem 
since  changes  to  the  source  code  are  now 
going  to  be  carried  out  by  the  utility  rather 
than  the  uaer.  This  is  accomplished  by  using 
fixed  specifications  along  with  ent  of 
several  bodies.  The  body  chosen  depends 
directly  on  the  operating  system  in  use. 


INTRODUCTION 

Heterogeneous  systems  are  incompat¬ 
ible  systems  because  of  dissimilarities 
in  both  thsir  properties  and  character¬ 
istics.  These  differences  are  most 
evident  in  their  keyboard  interfaces, 
file  management  system  support  functions 
and  T  1  routines,  and  communications. 

An  Ads  source  program,  which  is 
compiled  using  s  particular  compiler  and 
oparating  system,  will  not  be  able  to 
run  under  a.  different  operating  system, 
even  if  the  same  compiler  is  used, 
unless  changes  are  made  to  the  source 
code.  Hsking  these  changes  to  the  source 
code  is  undesirable,  especially  if  the 
program  has  to  run  on  msny  different 
systems,  since  this  process  is  both  tine 
consuming  and  expensive. 


In  their  book.  fcs.ttJiliJ.ijLW  and 
Swift,  ia  AsU  Cl).  John  Kissen  and  Pater 
Hall  is,  state  the  fact  that  “A  perfectly 
portabl*  Ada  program  would,  without  any 
change,  be  compilable  by  any  valid  Ada 
compiler".  Furthermore,  they  proposed 
the  equation  below  to  measure  the 
portability  of  any  given  Ada  code. 


(Cost  of  re-implementation  on 
the  naw  target) 

l . - . — . 

(Cost  of  originsl  implementation) 


If  thare  is  no  re-implamantatlon 
cost,  tha  formula  will  yiald  tha 
original  implanantation  cost. 

An  intermediate  layer  which  helps 
in  creating  different  images  out  of  ths 
cams  souroe  code,  depending  on  the 
environment,  relieves  the  user  from 
having  to  make  ths  changes  to  the  source 
code  himself.  This  will  set  the  re- 
implementation  cost  to  sere  and  the  cost 
of  the  development  will  not  be  affected 
by  any  overhead  due  to  the  new  code. 
The  layer,  which  sits  between  ths  user’s 
program  and  ths  operating  system,  will 
have  to  perform  ths  operating  system 
dependent  calls.  In  addition  to  its 
needsd  routines,  the  laye-  can  expand 
the  capabilities  of  ths  language  by 
including  other  User  needed  routines. 

Since  a  concept  rather  than  a  tool 
is  being  proposed,  the  File  Hansgement 
System  (FKS)  layer  is  being  focused 
upon,  as  sn  example,  since  the  same 
procedure  esn  be  followed  for  the  other 
lsyers. 

After  designing  and  implementing 
this  project,  a  driver  was  written  to 
test  all  of  the  operating  system's 
dependent  features  on  the  layer.  This 
driver  was  successfully  compiled  and 
executed  in  both  DOS  and  UNIX,  without 
requiring  any  chinges  or  modifications. 
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APPROACH 


The  foliating  steps  were  followed 
to  create  the  intermediate  layer.  As 
stated  in  Figure  1.  the  layer  can  be 
broken  Into  three  ma.ior  sections 
according  to  the  types  of  services  each 
section  is  to  provided. 

Section  1.  the  Communications 
Section,  will  allow  an  Ada  file  to  be 
transferred  between  different  machines. 
It  may  also  add  the  features  needed  for 
the  compilation  ef  code  on  a  distributed 
system. 

Section  2.  the  File  Hanagement 
System  and  I/O  Section,  will  provide  the 
Interfaces  from  the  user’s  program  to 
the  lower  Input  and  Output  application 
calls  of  the  operating  system. 

Section  3.  the  Keyboard  Interface 
Section,  uill  provide  a  compatible  input 
interface  regardless  of  the  system's 
keyboard. 


Comm. 

Section 


Ada 

Programs 


Keyboard 

Section 


File  Hanagement 
System 


Operating  System 


Figure  1 


As  stated  in  the  introduction  only 
the  FHS  layer  will  be  developed 
completely  in  thi3  exercise.  The 
operating  systems  used  were  Unix  and  DOS. 

The  FHS  layer  can  be  represented, 
using  the  Ada  language  as  the  designing 
tool,  as  an  Ada  package. 

This  package  will  contain  a  set  of 
specifications  that  is  common  to  both  of 
the  operating  systems  in  use.  The 
specifications  were  designed  using  the 
Unix  operating  system  semantics  as  the 
building  block.  Unix  was  chosen  rather 
than  DOS  simply  because  the  government 
prefers  that  operating  system. 


DESIGN 

The  specifications  for  the  FHS 
package  were  based  on  the  text_lo  pack¬ 
age  specifications  from  the  Ada  Language 
Reference  Hanual  (21.  In  addition  to 
the  routines  already  contained  in 
text.io,  additional  routines  were  added 
to  the  new  package  specifications  in 
order  to  handle  directory  related  calls. 
The  result  of  this  was  a  package  called 
Portable.Text.Io. 

In  order  to  facilitate  the  use  of 
the  new  package,  it  was  imperative  that 
the  Portable.Text.Io  package  ran  exaclty 
as  did  the  text.io  package.  Generic 
instantiations  of  the  generic  packages 
inside  the  text.io  specifications  were 
also  included  in  Portable.Text.Io.  In 
order  to  accomplish  this  abstract  view 
the  specifications  of  the  generic 
modules  in  the  new  package  included  e 
type  that  was  generic  not  only  to  the 
module  beign  developed,  but  also  to  the 
module  inside  text.io. 

After  the  set  of  specifications  was 
developed,  two  package  bodies,  one  for 
the  DOS  calls  and  one  for  the  Unix 
calls,  wtre  developed.  The  package  body 
that  handled  the  DOS  dependent  calls 
contslnad  the  pragma  interface  to  DOS  to 
perform  the  requested  call.  On  the 
other  hand,  the  Unix  dependent  calls 
were  handled  by  routines  written  in  C, 
and  utilised  pragma  interface  to  the  C 
language. 

In  Figure  2  we  can  see  how  the  oall 
generated  at  the  user  layer  will 
propagate  to  the  operating  system  layer. 
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CONCLUSION 

The  Department  of  Defense  l*  now. 
■or*  thtn  ever.  requiring  contractor*  to 
use  th*  Ads  programming  language  to 
develop  their  contracts.  In  order  for 
the  contractor  to  folly  satisfy  th* 
required  specifications  of  the  contract. 
h«  will  assign  different  parts  of  the 
contract  to  various  developers.  These 
developers  in  turn  say  use  different 
systeas  to  coaplete  their  individual 
task.  Once  the  separate  parts  are 
completed,  the  next  step  is  to  integrate 
then  on  to  the  target  computer. 

The  use  of  the  Portable_Text_Io 
package  uill  allow  the  user  to  run 
his  system  on  two  different 
environments,  namely  the  I8H  PC-AT  and 
the  SUNS  workstation. 

The  purpose  of  this  project  was  to 
set  an  example  of  how  to  develop  and 
implement  such  a  layer.  This  was  done 
by  using  two  characteristically 
different  machines,  the  IBM  PC-AT  and 
the  SDN  3  workstation,  running  DOS  and 
Unix  respectively . 
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Ad*  Compiler  Validation:  Purpose  and  Practice 


Boas  Williams  and  mil  Braahear 
SofTeeh,  Inc.,  Fairborn  OK 

Steve  Ullaon 
Vright-Patterson  AFB  OH 


Abstract 

Iba  real  waning  of  tha  tar*  "validated 
Ada  compiler"  la  oftan  misunderstood.  Ona 
mjawon  lnfaranca  la  that  tha  validated 
compiler  la  bug-free;  a  aacond  la  that  tha 
compiler  bahavaa  precisely  aa  apaclflad  by 
tha  Ada  language  Bafaranca  Manual  (LRM); 
atlll  another  perception  la  that  a  validated 
compiler  supports  every  feature  deaeribed  in 
tha  LRM  and  la  Judged  to  be  a  "good" 
compiler.  By  examining  the  validation 
process  and  the  teat  suite  on  which 
validation  is  based,  we  hope  to  correct  some 
of  these  misunderstandings. 


Tha  Unattainable  Coal  Of  Validation 

The  theoretical  goal  of  Ada  compiler 
validation  is  to  ensure  that  a  translation  system 
purchased  aa  an  Ada  compiler  obeya  tha  syntax  and 
seaantics  specified.  by  AN5I-MIL-3TD-1815A, 
Bafaranca  Manual  for  tha  Ada  Prograaalng  Language 
(LRM).  If  we  asauaa  that  this  goal  is  achieved, 
then  we  would  expect  that  an  Ada  prograa  would 
exhibit  the  sane  behavior  when  processed  by  any 
validated  coapilar  and  executed  on  that  compiler's 
target  syataa.  However,  there  are  at  least  two 
points  on  which  this  expectation  fails. 


if  we  assuae  that  validation  guarantees  that 
coapllera  adhere  strictly  to  all  the  ayntaotlc  and 
semantic  specifications  of  the  LBM. 

In  other  cases,  the  LBM  falls  to  coapletely 
specify  aoae  aeaantlc  behavior  without  explicitly 
saying  so.  For  example,  LBM  5.5/6  says  that  the 
parameter  of  a  FOB  loop  "is  an  objeot  whose  type 
is  the  base  type  of  the  discrete  range."  If  a  loop 
parameter  la  used  In  a  CASE  statement,  it  la 
Important  to  know  the  subtype  of  the  parameter  (In 
particular,  whether  the  subtype  la  atatlo).  To 
illustrate  this,  consider  the  following  code: 

for  INDEX  in  1  ..  100  loop 

came  INDEX  is 

when  1..50  *>  ...  ; 
when  51  ••  100  ■>  ...  ; 

end  emmet 

end  loopt 

If  the  subtype  of  INDEX  is  the  static  subtype  1  .. 
100,  then  the  CASE  stateaent  is  legal j  but  if  the 
subtype  of  INDEX  is  tha  base  type,  Integer,  then 
the  CASE  stateaent  is  illegal  because  no  OTHERS 
clause  ia  given.  Which  is  correct?  The  LBM  does 
not  coapletely  specify  the  seaantics  of  the 
situation,  so,  again,  two  validated  compilers 
could  produce  different  behavior  (one  rejecting 
the  program,  the  other  accepting  it). 

(Actually,  in  the  case  of  the  loop  parameter, 
the  standard  is  now  Interpreted  to  specify  that 
the  subtype  of  INDEX  is  determined  by  the  discrete 
range.  The  case  is  covered  by  AI-00006,  a  Binding 
Interpretation  of  the  standard,  approved  by  the 
International  Standards  Orgsnl zat ion's  Working 
Croup  9  (WC9)  and  the  Ada  Joint  Prograa  Office 
(AJP0)  in  July  of  1986.) 


Incomplete  Specification 


In  some  cases,  the  LBM  explicitly  leaves 
choices  to  the  implementation,  as  in  LRM  3.6-1/11: 
"For  the  elaboration  of  an  index  constraint,  the 
discrete  ranges  are  evaluated  in  some  order  that 
is  not  defined  by  the  language."  If  the  bounds  of 
the  discrete  ranges  in  an  index  constraint  are 
given  by  functions  with  side  effects,  then  the  LRM 
does  not  completely  speolfy  the  effect  of  the 
prograa.  It  is  quite  likely  that  two  validated 
compilers  would  produce  code  whose  execution  would 
exhibit  different  behavior  in  this  situation,  even 


Even  if  the  standard  were  perfect,  it  would 
not  be  possible  to  verify  absolute  conforaity.  It 
is  well  known  that,  for  a  program  with  any  sizable 
data  space,  exhaustive  testing  of  the  program  is 
impractical.  In  the  case  of  a  compiler,  the  data 
space  is  the  set  of  all  collections  of  text  files 
that  are  not  too  large  to  be  processed  by  the 
compiler.  To  guarantee  absolute  adherence  to  a 
standard  would  require  that  every  such  collection 
be  submitted  to  the  compiler,  with  the  criteria 
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that  every  collection  not  representing  a  local 
program  bo  rejected  and  that  ovary  collection 
representing  a  legal  program  exhibit  the  expected 
behavior.  Such  exhaustive  testing  Is  slaply  not 
feasible. 


report.  Finally,  the  implementer  has  attested 
that  no  extensions  to  the  language  have  been 
knowingly  Implemented.  These  characteristics  of 
an  Ada  compiler  should  give  the  Ada  user  assurance 
that  the  best  possible  effort  has  been  made,  by 
all  parties,  to  see  that  the  compiler  conforms  as 
closely  as  possible  tc  the  Ada  language  standard. 


The  Reality  of  Validation 

In  reality,  Ada  compiler  validation  depends 
on  the  completeness  and  correctness  of  the  Ada 
Compiler  Validation  Capability  (ACVC).  This  set 
of  test  programs  and  support  software  has  evolved 
with  the  Ada  effort.  It  la  not  complete  (In  the 
exhaustive  sense),  nor  will  It  ever  be  complete. 
The  current  version,  ACVC  1.10,  contains  over  3700 
test  programs,  but  Important  areas  of  the  language 
are  not  yet  tested.  Thus,  an  Ada  compiler  can  be 
tested  and  validated  without  correctly  supporting 
the  very  feature  that  a  particular  program  might 
depend  on. 

In  addition  to  its  being  forever  incomplete, 
the  ACVC  will  always  be  subject  to  error.  The 
tests  are  written  carefully,  with  constant  review, 
but  there  are  many  subtle  points  of  the  language 
that  do  not  come  to  light  until  someone  tries  to 
use  them.  For  example,  a  teat  may  make 
assumptions  that  are  valid  for  every  known 
Implementation  because  of  the  existence  of 
standard  Implementation  techniques.  Vet,  an 
lmplementer  who  Is  an  independent  thinker  may  use 
a  non-standard  technique  that  Is  permitted  by  the 
standard,  but  that  has  a  totally  unexpected  Impact 
on  the  test's  behavior.  This  situation  happens 
frequently,  and  will  continue  to  do  so  as  compiler 
technology  beoomes  more  sophisticated. 

Thus,  the  faot  that  an  Ada  compiler  is 
validated  does  not  guarantee  that  it  adheres 
precisely  to  the  standard,  for  such  a  guarantee  Is 
Impossible.  It  most  certainly  does  not  guarantee 
that  the  compiler  contains  no  "bugs,"  for  the  test 
suite  la  not  designed  for  debugging  (although 
implementors  do  often  find  bugs  when  running  the 
ACVC).  Validation  does  not  ensure  that  compilers 
are  efflolent,  either  In  terms  of  time  or  memory 
usage,  for  there  are  no  tests  for  efficiency  in 
the  suite.  It  does  not  guarantee  that  large, 
complex  programs  can  be  handled  correctly,  for  the 
test  suite  consists  of  many  small  programs, 
designed  to  teat  speolfic  language  features. 


Vhat,  then,  Is  the  meaning  of  validation? 
What  can  we  assume  about  a  validated  Ada  compiler? 
First,  a  validated  Ada  compiler  has  correctly 
processed  the  most  widely  portable  body  of  Ada 
software  in  existence.  Second,  it  has  done  so 
under  the  supervision  of  an  Impartial  validation 
team,  and  the  validation  report  produced  by  that 
team  has  been  scrutinized  by  the  vendor  and  by 
another  Impartial  validation  agency.  Third,  any 
behavior  not  strictly  in  accordance  with  the 
expectations  of  the  test  suite  has  been  ruled 
Justifiable  by  the  validation  agencies  <<od  has 
been  thoroughly  documented  in  the  validation 


The  Validation  Process 

The  purpose,  in  theory,  of  Ada  compiler 
validation  testing  la  to  verify  the  conformity  of 
an  Implementation  with  the  Standard,  Mil-Standard 
1S15A.  Aa  may  be  apparent  from  this  stated 
purpose,  "compiler"  validation  testing  Is  actually 
a  misnomer.  In  fact,  the  entire  implementation, 
Including  the  compiler  and  the  host  and  target 
computers  and  operating  systems,  la  really  tested 
because  a  change  to  any  part  of  the  Implementation 
can  affect  compilation  results.  According  to  MIL- 
3T0— 1 8 1 5 A ,  also  known  as  the  Ada  Language 
Reference  Manual  (LRM),  an  Implementation  conforms 
to  the  Standard  if  and  only  If  It  satisfies  each 
of  the  following  six  requirements! 

1.  It  correctly  translates  and  executes 
legal  Ada  program  units  that  do  not 
exceed  the  capacity  of  the 
implementation. 

2.  It  rejects  all  program  units  that  exoeed 
the  Implementation's  capacity. 

3.  It  rejects  all  program  units  containing 
errors  that  the  LRM  requires  are  to  be 
detected. 

A.  It  supplies  all  predefined  program  units 
that  the  Standard  requires. 

5.  It  contains  no  variations  except  as 
allowed  by  the  Standard. 

6.  It  specifies  variations  permitted  by  the 
Standard . 

A  true  all-inclusive  conformity  verification  needs 
to  cover  all  six  requirements  and  thus  ensure  that 
the  implementation  Is  neither  a  "subset"  nor  a 
"superset"  of  the  Ada  language. 

It  is  Impractical,  if  not  Impossible,  to 
verify  an  implementation's  conformity  to  the 
Standard.  For  example,  to  check  that  the 
Implementation  rejects  all  program  units 
containing  errors  would  require  that  all  possible 
errors  be  identified  and  a  test  be  written  for 
each  une,  an  endless  exercise. 


What  can  and  has  been  done,  however,  is  to 
develop  a  measuring  stick  of  conformity.  This 
measuring  stick  is  called  the  Ada  Compiler 
Validation  Capability  (ACVC).  As  a  first  step  in 
developing  the  ACVC  test  suite,  the  LRM  was  broken 
into  discrete  test  objectives.  The  resulting 
document  was  the  ACVC  Implementers'  Guide  (AIG). 
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To  obUln  a  base  validated  compiler,  »n 
lmplementer  must  contract  with  om  of  five  Ada 
Validation  Facilities  (AVFs)  to  perform  th« 
validation.  The  laplaiaantar  obtains  a  copy  of  the 
AC VC  test  suite. 


Fre validation 

Once  the  lmplementer  has  run  the  ACVC  testa 
on  his  implementation  and  believes  that  he  has  a 
complete  and  correct  set  of  test  results,  he 
submits  these  results,  called  prevalldatlon 
results,  to  his  AVF  for  snalyals.  Xf  the 
lmplementer  finds  tests  he  believes  incorrectly 
showed  that  the  compiler  failed  these  testa,  he 
submits  arguments  to  the  AVF  disputing  those 
tests.  The  AVF  forwards  the  arguments  to  the  Ada 
Validation  Organisation  (AVO)  which  handles  test 
disputes  sent  then  rrom  all  AVFs.  For  each  teat, 
the  AVO  decides  either  that  the  lmplementer  oust 
change  his  conpller  to  pass  the  test  or  that  the 
test  nay  be  deolared  not  applicable  for  the 
subjeot  laplenentatlon.  When  the  AVF  has  received 
fron  the  laplenenter  all  ACVC  teat  results  and  has 
graded  each  test  as  either  "passed"  or  "not 
applicable",  prevalldatlon  la  conplete.  Failed 
tests  must  be  resolved  before  prevalidation  is 
considered  conplete. 


On  Site  Testing 

Once  prevalldatlon  is  conpleted,  an  AVF  test 
teaa  travels  to  the  laplenenter 'a  site  on  a 
prearranged  date  and  takes  with  then  the  ACVC  test 
suite,  custonlsed  Tor  the  laplenentatlon  under 
test.  On  site,  the  test  teaa  loads  the  ACVC  onto 
the  laplenentatlon  under  test  and  verifies  that 
on-slte  results  natch  the  previous  prevalldatlon 
results. 

Once  the  laplenenter  has  successfully 
conpleted  on-slte  testing  and  has  signed  a 
Declaration  of  Conforaance,  afflralng  coapliance 
to  the  LRM  as  aeasured  by  the  ACVC,  the  AVF  sends 
a  notice  of  coapletlon  of  on-slte  testing  to  the 
AVO.  When  the  AVO  determines  that  the  validation 
atteapt  '  successful,  they  direct  that  a 
Validation  Ceriflcate,  listing  both  the 
laplenenter  and  laplenentatlon,  be  sent  to  the 
validation  customer.  A  copy  of  the  validation 
certificate  is  aalntalned  by  the  AVO  and  serves  as 
the  permanent  validation  record. 

The  Validation  Suaaary  Report 

Following  on-slte  testing,  the  AVF  prepares  a 
Validation  Suaaary  Report  (VSR)  which  describes 
the  laplenentatlon  tested,  the  detailed  procedures 
used  In  the  validation,  and  the  tests  declared  not 
applicable.  All  coapller  switch  settings  used  in 
the  validation  are  recorded  in  the  VSR.  One 
purpose  of  the  VSR  is  to  allow  the  validation  to 
be  coapletely  reproduced.  This  capability  could 
become  extreoely  important  if  a  compiler's 
conforaance  is  challenged. 


The  VSR  highlights  several  validation 
shortcomings.  An  implementation  is  tested  for  a 
speolfic  coapller,  host,  target,  operating  aystea, 
and  set  of  switch  settings  Including  optimisation. 
It  la  quite  possible  for  ACVC  test  results  to 
differ,  If  even  one  component  of  the 
Implementation  Is  only  slightly  changed. 

An  lapleaenter  typically  validates  under  one 
set  of  switch  settings  and  sells  the  coapller,  as 
a  validated  Ada  compiler,  under  a  different  set  — 
one  that  provides  better  performance.  Bit  the 
compiler  cannot  necessarily  be  expected  to  pass 
the  same  set  of  ACVC  tests  when  the  switches  have 
been  changed.  The  dllema  has  been  discussed  by 
the  Ada  Certification  Body  and  to  some  extent 
resolved.  The  Validation  Certificate  does  not, 
due  to  space  limitations,  list  all  switch  settings 
used  In  the  validation.  Only  the  VSR  lists  the 
validated  switch  settings  used  In  the  validation 
and  for  which  the  ACVC  test  results  apply.  Thus, 
the  VSR  serves  as  the  authoritative  and  complete 
validation  documentation  supporting  the  validation 
certificate. 


Derived  Implementations 

Implementors  have  effectively  argued  that  to 
require  that  a  base-validation  be  performed  for 
every  possible  compiler  on  every  possible 
host/target  configuration  is  both  Impractical  and 
unnecessary.  To  validate  for  every  variation  of 
host,  target,  compiler  maintenance  update  and 
every  combination  of  all  three  would  create  more 
base-validations  than  could  reasonably  be  expeeted 
to  be  completed.  Furthermore,  there  exist  many 
Implementations  slightly  different  than  a  base- 
validated  implementation  that  would  reasonably  be 
expected  to  conform  exactly  as  the  base  does.  For 
example,  it  Is  completely  reasonable  to  expect 
that  a  compiler  will  behave  similarly  on  any  VAX 
within  the  entire  VAX  family,  and  there  are  many 
minor  upgrades  to  compilers  to  Improve  performance 
that  do  not  In  any  way  affect  conformance. 

To  accommodate  those  instances  when  an 
implementation  Is  so  similar  to  a  base-validated 
implementation  that  it  would  reasonably  be 
expected  to  perform  exactly  as  the  base,  the 
Certification  Body  has  permitted  such 
Implementations  to  be  registered  as  derived 
compilers.  Derived  compilers  are  validated 
compilers.  The  basis  for  the  validation  status 
lies  only  with  the  compiler's  documented 
similarity  to  a  base-validated  compiler.  To 
register  an  implementation  as  a  derived 
implementation,  an  lmplementer  submits  a  request 
to  the  AVF  that  performed  the  base-validation. 
The  lmplementer  provides  his  rationale  for  the 
derivation,  documentation  supporting  that 
rationale,  and  a  signed  Declaration  of  Conformance 
listing  the  base  and  candidate  derived 
configurations.  Tte  AVK  reviews  the  rationale  and 
supporting  documentation  and,  if  derivabillty 
seems  plausible,  recommends  to  the  AVO  that  the 
derivation  be  accepted.  When  the  AVO  concurs  with 
the  opinion  of  the  AVF,  they  direct  that  the  now- 
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derived  compiler  be  «dd*d  to  th«  validated 
compiler  Hat. 

Users  should  be  a war*  that,  although  a 
derived  implementation  Is  valldatad,  It  has  not 
baan  taatad  against  tha  ACVC  by  an  Indapandant 
taat  organisation.  Consequently,  tha  conformance 
dapands  to  a  such  graatar  dagraa  than  a  base- 
y»Ud-iiori  on  tha  affirmation  of  tha  compiler 
implemented 


Conformance  Testing 

Validation  daals  only  with  confomanea 
tasting.  It  doas  not  tast  tha  affloiancy  or  tha 
parfomanca  of  tha  compiler.  Sines  affiolaney  and 
parfomanca  ara  Important  in  evaluating  tha 
utility  of  a  compiler,  validation  cannot  possibly 
Indicate  how  "good"  tha  compiler  is,  where  "good” 
refers  to  the  compiler's  performance  and 
affiolaney. 

Validation  is  limited  in  its  tast  of 
conformity  by  practical  limitations  »r.d  procedures 
established  by  tha  Ada  Certification  Body  and  by 
limitations  of  tha  ACVC  itself.  The  ACVC  is  a 
measure  and  not  a  litmus  tast  of  the  conformity  of 
an  Ada  compiler.  To  understand  both  tha  value  and 
limitations  of  tha  ACVC,  it  is  important  to  know 
how  tha  tast  suite  is  structured. 


Tha  Ads  Compiler  Validation  Capability  (ACVC) 

Tha  ACVC  is  a  changing  body  of  tests.  Up 
until  now,  a  new  version  has  baan  released  every 
year.  As  of  tha  writing  of  this  paper,  tha 
currant  version  is  ACVC  1.10  which  was  released  as 
a  pra-ralaaaa  version  on  1  December  1957}  it  was 
released  as  a  final  version  on  1  May  1988  and 
became  the  official  version  for  use  in  validations 
on  1  June  1988. 

The  tests  in  the  suite  are  based  upon  the 
LRM,  as  Interpreted  by  the  ACVC  Implementors' 
Guide  (AIG).  Basically,  the  AIG  follows  the 
chapter,  section,  and  subsection  structure  and 
numbering  of  the  LSM.  The  AIG  lists  test 
objectives  for  each  subsection.  Each  objective  is 
designed  to  cover  one  atomic  feature  of  the  Ada 
Language.  The  tests  are  also  written  atomically; 
one  language  feature  is  covered  per  test. 

Each  of  the  tests  in  the  suite  is  a  short  Ada 
language  program.  Most  of  theso  are  executable, 
and,  if  executed  properly,  will  write  the  test 
name  followed  by  the  word  "PASSED"  to  standard 
output.  There  are,  however,  tests  which  are  not 
meant  to  execute.  These  test  programs  contain 
intentional  semantic  or  syntactic  errors  and  were 
written  for  the  purpose  of  determining  whether  a 
compiler  can  detect  these  errors. 


Classes  of  Testa 

The  tests  of  the  ACVC  are  divided  into  six 
classes,  A  testa,  B  teats,  C  tests,  D  tests,  t 
tests,  and  L  tests.  Class  A  tests  check  that  a 
compiler  doea  accept  certain  legal  Ada  language 
features.  For  example,  there  la  an  A  test  which 
checks  that  compilers  accept  an  enumeration  type 
definition  which  contains  a  single  enumeration 
literal.  Class  B  tests  check  that  compilers 
reject  constructs  which  are  not  legal  Ada  language 
features.  For  example,  there  lu  -  B  test  which 
check*  that  a  compiler  rejects  an  enumeration  type 
definition  which  consists  of  empty  parentheses, 
l.e.,  which  contains  no  enumeration  literals. 
Class  C  test  check  that  a  compiler  not  only 
accepts  legal  Ads  code,  but  also  that  the  code  is 
executed  correctly.  For  instance,  a  C  test  might 
check  that  not  only  are  logical  operators  for 
arrays  of  Boolean  elements  accepted,  but  also  that 
such  operations  yield  a  correct  result.  Class  9 
tests  check  compiler  capability.  There  la  a  9 
test  which  determines  the  number  of  nested  block 
statements  that  a  compiler  can  support. 

A  compiler's  performance  on  A,  C,  and  9  tests 
is  usually  judged  by  whether  the  successful 
compilation,  linking,  and  execution  of  the  test 
results  causes  a  message  containing  the  word 
"FA53EO"  to  be  printed.  For  class  B  tests,  a 
compiler's  performance  is  Judged  by  tha  compiler's 
finding  an  error  at  those  places  indicated  in  the 
test.  Class  E  is  for  tests  tha  performance  of 
which  cannot  be  Judged  by  either  of  the  above 
methods.  For  example,  some  olass  E  tests 
determine  whether  praxes  LIST  and  pragma  FACE 
behave  correctly.  These  tests  must  not  only 
compile,  link,  and  execute  correctly,  but  must 
also  produce  correct  listing  files.  The  final 
class,  olass  L,  consists  of  tests  that  should 
compile  correctly  but  which  must  fall  at  link 
time.  An  example  of  such  a  test  would  be  one 
which  consists  of  a  main  program  for  which  a 
necessary  subunit  la  missing  from  the  program 
library. 

By  convention,  the  name  of  a  test  Indicates 
the  olass  of  the  test  and  the  chapter,  section, 
and  subsection  or  the  LRM  to  which  the  test 
pertains,  and  the  number  of  the  test  objective  in 
the  AIG.  For  example,  if  the  name  of  a  test  is 
"A35101B",  then  the  first  character  indicates  that 
this  is  a  class  A  test.  The  second  through  fourth 
characters  indicates  that  the  tests  covers  an 
objective  taken  from  subsection  3.5.1  of  the  LIW. 
The  last  three  characters  indicate  that  the  test 
is  based  upon  the  second  part  (part  B)  of  the 
first  test  objective  in  that  subsection. 


Version  1.10  of  the  ACVC 

Version  1.10  of  the  test  suite  consists  of 
3717  tests,  an  increase  of  621  tests  over  version 
1.9.  The  major  portion  of  new  tests  covers  issues 
from  Chapter  13  of  the  LRM,  "Representation 
Clauses  and  Implementation  Dependent  Features."  In 
writing  these  tests  the  attempt  was  made  to 
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Include  not  only  those  construct*  which  night  be 
almost  universally  implemented,  but  also 
oon*truct*  which,  although  supported  by  th« 
language,  ar«  not  usually  supported  by 
Implement*™.  An  example  of  th«  former  la  a  tost 
which  night  make  use  of  a  also  clause,  spool  ring 
an  a  also  equal  to  INTSCER'SIZE  divided  by  two  and 
applied  to  a  snail  Integer  type.  Examples  of  the 
latter  can  be  found  In  teats  which  provide  address 
specification  clauses  for  subprogrsns  and  task 
units.  Another  exsnple  of  the  tatter  can  be  found 
In  teats  which  first  declare  a  floating  point 
type,  FLOATS,  with  precision  five  and  then  specify 
that  the  sis*  of  FLOAT1,  a  floating  point  type  of 
precision  one,  should  be  FLOATS'SXZE  divided  by 
two. 

Much  of  the  controversy  surrounding  the 
Chapter  13  testa  stens  fron  the  faet  that  up  until 
now,  little  or  no  effort  has  been  nade  to 
establish  a  unifom  Interpretation  of  the  Issues 
in  Chapter  13.  Although  the  teats  In  the  suit* 
are  not  Intended  to  resolve  the  Issues,  the  testa 
have  caused  nay  questions  to  be  raised.  ror 
instance,  concerning  the  sis*  of  a  type  the  INK 
clearly  states!  "X’SIZE  ...  Applied  to  a  type  or 
subtype,  yields  the  minimum  nuaber  of  bits  that  is 
needed  by  the  Implementation  to  hold  any  possible 
object  of  this  type  or  subtype."  Xf  BOOLEAN'SIZE 
for  a  given  lnplenentatlon  Is  on*  bit,  does  this 
a*an  that  any.  object  of  type  BOOLEAN  can  fit  into 
one  bit?  It  sees*  as  lr  the  answer  to  this 
question  should  be  "XE3."  Tet,  It  Is  not  uncommon 
for  an  Implementation  which  reports  a  sis*  of  on* 
bit  for  type  BOOLEAN  to  require  four  bits  or  eight 
bits  to  hold  a  BOOLEAN  object  which  is  an  array  or 
a  record  component.  Xf  B  1*  an  objeot  of  type 
BOOLEAN,  then  what  Is  the  relationship  between 
B'SIZE  and  BOOLEAN’SIZE?  Xs  there  necessarily  any 
relationship? 

Another  item  upon  which  there  la  some 
disagreement  la  the  relationship  between  a 
STORAGE  SIZE  olaus*  and  the  STORAGE  SIZE 
attribute.  If  a  ST0RAGEJ5IZE  clause  specifies  a 
collection  sis*  of  102b  storage  units  for  an 
access  type  T,  then  can  an  Implementation 
legitimately  reserve  more  apace  for  the  collection 
than  specified?  Furthermore,  what  value  should  be 
returned  by  the  attribute  T'STORAOE_SIZE?  If  more 
spec*  is  reserved  than  the  amount  specified,  then 
must  the  T'ST0RAGE_3IZE  attribute  return  the 
actual  amount  of  space  reserved,  or  should  the 
attribute  merely  return  the  number  of  units 
apeoifled?  Does  it  matter  what  value  the 
attribute  returns?  Of  what  us*  is  the  valus 
returned  by  the  attribute?  Should  an 
implementation  be  Judged  to  be  In  error  if  the 
value  of  the  attribute  does  not  reflect  exactly 
the  amount  of  storage  reserved?  If  no 
representation  clause  is  given  for  f,  then 
although  a  compiler  cannot  reject  the  expression 
T'STORAGEJSIZE,  what  value  does  this  expression 
have?  “ 

No  discussion  of  Chapter  13  issues  would  be 
complete  without  a  word  about  addresses  and 
address  clauses.  It  appears  that  few,  if  any, 
implementations  support  address  clauses  for 
subprograms,  tasks,  or  packages.  However,  is  it 
totally  impractical  for  an  implementation  to 
support  such  address  clauses  for  program  units? 
If  so,  then  why  are  such  constructs  supported  by 


the  language?  Although  it  is  legal  to  put  an 
address  clause  for  an  object  declared  Inside  of  a 
subprogram  or  even  Inside  of  a  nested  subprogram, 
does  it  really  make  sens*  to  refer  to  the  address 
of  such  a  local  object?  Csn  an  Implementation 
legitimately  return  the  same  value  (a  value  of 
xero,  for  example)  for  all  label  names  and  block 
names?  As  of  today,  most  of  the  Issues  Involving 
Chapter  13  tests  are  yet  to  be  resolved.  The 
debate  continues. 


iJntestable  Objectives 

Although  the  goal  of  the  ACVC  Is  to  provided 
as  thorough  coverage  of  the  language  as  possible, 
there  are  some  tests  which  implemented  should  not 
expect  to  see  in  any  of  the  upcoming  versions, 
ilost  of  these  may  be  found  In  Chapter  lb  of  the 
LRM.  For  example,  there  are  no  tests  upcoming 
whleh  Involve  low  level  Input  and  output.  Since 
the  procedures  (ineluding  the  parameters) 
specified  in  the  package  LOWjLEVELJtO  are  left 
totally  up  to  the  Implementation!  there  Is  no 
practical  way  to  aaoertain  that  they  behave 
correctly.  Another  test  that  la  not  forthcoming 
Is  a  teat  that  checks  that  the  exception 
DEYICE_EfiROR  Is  raised  as  specified  by  the  LRM, 
1.*.,  "when  there  la  a  malfunction  of  the 
underlying  system.  The  writing  of  this  teat  la 
swsitlng  the  discovery  of  a  harmless  way  to  causa 
a  system  to  malfunction. 


Future  of  the  ACVC. 

Xh*  future  of  the  ACVC  la  uneltar  at  this 
time.  Version  1.11  is  In  the  development  stag*. 
It  will  be  in  many  ways  like  version  1.10.  Ih* 
major  blocks  of  new  tests  will  come  from  Chapter  8 
of  the  LRM  (tests  dealing  with  visibility  and 
renaming),  Chapter  13  (taats  dealing  with  more  of 
tht  same  issues  as  thoaa  Chapter  13  teats  In 
varalon  1.10),  and  from  Chapter  1  (taats  dealing 
mainly  with  type  conversions  and  with  real 
arithmetic).  What  happens  to  the  suit*  after 
version  1.11  is  still  "up  in  the  air."  On* 
proposal  is  that  the  suit*  be  "frozen"  at  version 

1.11  and  that  although  revisions  to  existing  tests 
will  be  allowed,  there  will  be  no  new  tests 
written.  Another  idea  is  to  product  a  version 

1.12  of  the  suit*  in  the  same  way  as  previous 
versions  have  bean  producad.  A  third  proposal  is 
that  tha  philosophy  behind  the  ACVC  and  its  us#  be 
changed.  A  new  suit*  of  tests  would  be  produced 
in  which  each  test  will  check  combinations  of 
features  rather  than  a  single  feature.  Whether 
the  test  suit*  will  take  on*  of  these  three 
directions  or  some  other  direction  must  await  the 
decision  of  the  Ada  Maintenance  Organization  (AMO) 
with  the  approval  of  the  Ada  Joint  Program  Office 
(AJPO) . 
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AfetUract 

TEXT^IO  is  the  standard  Ads  package  for 
inpul  and  output  of  character  data.  It  is 
commonly  used  to  transfer  data  between 
devices  and  files.  Unfortunately,  its 
specification  is  inconsistent  and  loose 
enough  that  vendors  have  implemented  it 
differently,  resulting  in  portability 
problems  and  surprising  quirks,  these 
surprises  make  10  annoying  and  frustrating 
to  most  Ada  beginners,  and  even  to  a  few 
seasoned  veterans.  To  Make  natters  worse, 
TEXT^tO  was  designed  to  be  a  file 
Interface,  but  it  is  often  pressed  into 
service  as  a  user  interface.  It  doesn't  do 
this  job  very  well,  so  application 
programs  that  use  TEXT^IO  for  a  user 
Interface  tend  to  stake  users  unhappy. 

Ifttr-OdtfSUofl 

This  paper  describes  some  of  the 
portability  problems  you  are  likely  to 
have  if  you  use  TEXT^IO.  It  tells  why  a 
file  written  by  TEXT^IO  on  or.e  machine 
might  not  be  read  correctly  on  a  second 
machine,  and  why  a  program  that  works 
properly  on  one  machine  puts  a  blank  line 
between  user  prompts  (or  writes  prompts  on 
top  of  each  other)  when  transferred  to 
another  machine. 

You  will  also  find  out  why  quirks  in 
TEXT^IO  cause  some  programs  to  seem  to 
skip  over  user  inputs  without  processing 
them.  I'll  show  you  how  to  write  numbers 
and  enumeration  types  in  ASCII  format 
without  instantiating  a  generic  10 
package.  Finally,  I'll  suggest  some  other 
user  interfaces  that  eliminate  the  need 
for  TEXT_IO  entirely. 

File  Portability  Problems 

Suppose  you  have  a  data  file  (containing 
numbers,  not  text)  that  you  want  to 
transfer  to  a  second  computer.  You  know 
better  than  to  try  to  transfer  binary 
files.  The  two  machines  might  use  a 
different  number  of  bits  to  represent 
integers,  so  each  integer  written  by  a  32- 
bit  machine  would  get  "unpacked"  into  two 


integers  on  a  16-bit  machine.  Even  if  both 
■vhlnes  use  the  same  number  of  bytes  per 
integer,  one  might  store  the  high  byte 
first  while  another  might  store  the  low 
byte  first.  Floating  point  numbers  are 
even  less  portable  because  there  are  so 
many  different  ways  to  represent  them. 
(VAX/VMS*  uses  A  different  Internal  forms 
for  real  numbers.)  Different  computers 
generally  use  different  numbers  of  bits 
for  the  mantissa  and  exponent.  You  are 
asking  for  trouble  if  you  try  to  transfer 
files  in  binary  format. 

You  might  think  you  can  avoid  all 
those  problems  by  using  TEXT.IO  to  convert 
the  numbers  to  character  strings  in  a  text 
file,  and  then  transfer  the  text  file  from 
one  machine  to  the  other.  Well,  it's  not 
that  simple.  You  may  discover  that  files 
written  by  one  machine  will  raise 
COS’S  TEA  IXT_  ERROR  or  PATA^ERROR  when  read 
on  another  machine.  That's  not  so  bad, 
because  at  least  you  know  there  is  a 
problem.  Sometimes  your  data  will  be 
skewed  forward  or  backward  one  location  in 
the  file,  causing  the  data  to  be  read  into 
the  wrong  variables.  (That  is,  the  value 
for  the  third  element  of  an  array  may  end 
up  in  the  second  or  fourth  element. )  When 
this  happens,  there  may  not  be  an  error 
message. 

User  lntcrface_Pcf.lclei>cie» 

TEXT^IO  makes  a  terrible  user  Interface. 

It  treats  the  user's  terminal  just  like  a 
file  and  lacks  features  that  humans  need. 
Files  never  make  mistakes,  so  they  don't 
need  a  rub  out  key.  Files  never  enter 
passwords  which  shouldn't  be  echoed  to  the 
screen.  Files  never  want  to  insert  or 
delete  text.  Files  never  need  help,  or 
want  to  enter  the  default  response.  Files 
never  want  to  clear  a  screen  or  move  a 
cursor.  Files  never  realise  the  program 
has  run  amok  and  try  to  send  an 
unsolicited  CTRL-C  to  stop  the  process. 
Files  never  want  to  press  a  special 
function  key.  Users  often  want  uo  all 
these  things,  but  TEXT_I0  won’t  let  them 
because  it  wasn't  designed  to  support 
people. 
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y*tr_Jnt.erfs§e. 

The  Get  and  Gei.Unc  procedures  don't 
work  the  way  wont  people  seen  to  expect 
the*  to.  How  Many  people  have  tried  to  uac 
TEXTmIO.Get(C  :  character!  to  try  to  build 
a  line  editor,  only  to  discover  that  no 
natter  what  you  do,  It  won't  respond  to  a 
carriage  return?  How  nany  people  have 
written  programs  with  a  Mixture  of  Cot  and 
Get_Li/i<?  procedures  that  seemed  to  hang 
forever,  or  take  data  before  the  user 
entered  It?  Practically  every  Ada 
programmer,  1  bet. 

When  this  happens,  don’t  blame  the 
compiler  vendor.  There's  nothing  wrong 
with  the  compiler.  It's  Just  conforming  to 
the  specification.  You'll  see  why  after  we 
examine  some  of  the  strange  passages  in 
the  Ada  Language  Reference  Manual  (I.RH). 

User  Interfere. JpoxtftklJUlUC 

Since  input  data  editing  might  not  be 
done  by  the  operating  system  service 
called  by  the  Get  procedure,  you  never  can 
tell  If  CTRL-. X  will  erase  a  whole  line,  or 
if  backspace  will  be  the  sane  as  delete. 
You  night  alao  discover  that  a  program 
that  runs  fine  on  one  system  does  strange 
things  on  another.  The  user  prompts  might 
appear  on  consecutive  lines  on  the  first 
machine,  but  may  have  blank  lines  between 
them  on  a  second  machine.  Worse  yet,  the 
prompts  might  appear  on  top  of  each  other 
on  another  machine. 

CHUsrjL  Pf-T£XT_10  Problems 

T  US  OCX  SS.t  J.mplc  men  X,  at  Aon  * 

Six  years  ago,  Ada  pioneers  had  to  use 
unvalldated,  partial  implementations. 

Those  compilers  were  full  of  bugs.  In 
those  days,  there  were  some  10  errors 
because  TK.\T_JO  wasn't  implemented 
correctly.  I  haven't  seen  a  problem  that 
was  the  result  of  a  TEXT_TO  implementation 
error  in  the  last  few  years,  but  I  think 
there  is  still  a  tendency  to  blame  the 
compiler  whenever  TEXT^IO  doesn't  work  the 
way  the  programmer  thinks  it  should.  Even 
in  those  cases  where  a  program  runs 
differently  with  two  different  versions  of 
TEXT..IO,  you  can't  be  certain  either  of 
them  is  wrong  because  the  specification 
allows  so  many  options. 


Loos  e_  Spec  i  float  io.n 

TEXT^IO  leaves  some  important  details 
unspecified.  Here  are  two  troublesome 
passages  in  the  LHM: 

"The  actual  nature  of  terminators  is 
not  defined  by  the  language  and 
hence  depends  on  the  implementation. 
Although  terminators  are  recognised 
or  generated  by  certain  or  the 
procedures  that  follow,  they  are  not 
necessarily  Implemented  as 
characters  or  as  sequences  of 
characters.  Whether  they  are 
characters  {and  if  so  which  ones)  in 
any  particular  implementation  need 
not  concern  a  user  who  neither 
explicitly  outputs  nor  explicitly 
inputs  control  characters.  The 
effect  of  input  or  output  of  control 
characters  (other  than  horlxonlal 
tabulation)  is  not  defined  by  the 
language."  LRM  section  14.3 
paragraph  7 

"A  page  terminator  is  always  skipped 
whenever  the  preceding  line 
terminator  is  skipped.  An 
implementation  may  represent  the 
combination  of  these  terminators  by 
a  single  character,  provided  that  it 
is  properly  recognixed  at  input." 

LRH  section  14.3.4  paragraph  51 

In  other  words,  there  is  no  guarantee  that 
two  different  implementations  of  TEXT^IO 
will  use  the  same  terminators.  Therefore, 
the  line-,  page-,  and  file-terminators 
generated  by  machine  1  night  be  mistaken 
for  data  by  machine  2  and  generate 
DATA^ERROR  exceptions.  Perhaps  the 
difference  in  terminators  night  not  be 
detected  at  all,  resulting  in  "off  by  one 
errors”  (that  is,  reading  item  N+l  when 
you  think  you  are  reading  item  N). 

Here’s  a  fictional  example  that 
illustrates  what  could  happen:  When 
Machine  1  writes  a  line,  it  writes  "some 
string”<CRXLF>.  The  carriage-return/line¬ 
feed  sequence  is  the  line  terminator  for 
Machine  1.  But  Machine  2  night  write  a 
line  with  the  line  spacing  first,  so  lines 
look  like  <LF>"some  string"<CR>.  It 
considers  the  line  feed  to  be  a  character, 
and  the  carriage  return  alone  to  be  the 
line  terminator.  Suppose  you  use  these  Ada 
statements  to  write  a  few  lines  to  a  file: 
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put_l lne (FILEi "A" } 5 

pul.llnet  FILE,  "»•*); 

puKFILE.'X'  A  ASCII. CR  A  ASCII. LF); 

put_lln*(FILE,“C“) ; 

If  Machine  1  write*  to  FILE1.EXT  ant) 
Machine  2  wrlt<ss  to  FILES. EXT,  then  the 
contents  of  those  files  will  he  as  shown 
below.  (Let  <EOPn>  and  <E0Fn>  represent 
the  end  of  page  and  end  of  file  Markers  on 
Machine  n,  which  night  not  be  the  sane.) 


FILE! .EXT  FILE2.EXT 


A<CRXLF> 

B<CRXLF> 

X<CRXLF> 

C<CRXLF> 

<EOPi > 

<EOFl> 


<LF»A<CR» 

<LF>B<CR> 

<LF>X<CRXLF> 

<LF>C<CR> 

<E0P2> 

<E0F2> 


Suppose  you  have  written  an  Ada 
program  called  List  which  uses  TFXT^IO  to 
list  files,  as  long  as  FILEI.KXT  remains 
on  Machine  1  and  FILES. EXT  remains  on 
Machine  2,  there  isn't  any  problem.  This 
is  what  you  will  see: 

Machine_l>LIST  FILEI.KXT 

A 

B 

X 

C 


Mach ine_2> LIST  FILE2.EXT 

A 

B 

X 

C 


But  suppose  you  transfer  each  file  to 
the  other  machine.  Here's  what  happens: 

Hacblne_l>LIST  FILE2.F.XT 

A 

B 

X 

C 

(Letter  C  might  be  immediately  covered  by 
an  error  message,  caused  by  a  bad  end  of 
page  or  end  of  file  terminator.  If  not,  it 
will  probably  be  covered  by  the  Machine_l 
prompt. ) 


Maehine.2  "LIST  FI LEI .EXTA 
B 
X 
C 

(Prompt  or  possible  error  message  here.) 

This  example  illustrates  an  annoying, 
but  not  critical,  quirk.  Suppose,  however, 
FI LEI .EXT  and  FILES. EXT  were  data  files. 
The  first  data  item  Is  A,  but  Machine  1 
would  think  the  first  data  item  is  a  blank 
line,  ami  Machine  2  would  think  the  first 
item  is  B.  This  could  result  in 
COSSTFA f ,ST_ ERROR ,  or  perhaps  wrong  answers 
without  sny  error  indication.  If  the  page 
terminators  or  file  terminators  arc 
different,  it  could  raise  0ATA.FRRQR • 
Failure  to  define  standard  terminators 
leaves  the  door  open  for  all  sorts  of 
nasty  portability  problems. 

Nupo.rlc  .Limits 

A  potential  difference  in  line 
terminators  isn't  the  only  problem.  Even 
If  two  machines  use  the  same  terminators, 
you  can  still  run  Into  trouble  porting 
files  containing  ASCII  representations  of 
numbers.  The  siring  representation  of  a 
32-bit  integer  may  not  be  an  allowable 
value  for  a  IC-bit  integer.  The  maximum 
AFT  field  sixes  in  FLOAT.IO  and  FIXFD.W 
might  be  different  on  two  different 
machines,  and  the  machine  with  the  smaller 
AFT  field  might  raise  an  exception  if 
there  are  loo  many  characters  in  that 
field. 

To  be  honest,  this  Isn't  really  a 
TEXT^IO  problem,  It  is  a  machine 
capability  problem.  It  only  appears  to  be 
a  TFXT^JO  problem  because  you  don't 
discover  it  until  you  try  to  use  or 
instantiate  the  numeric  10  packages  in 
TEXT^IO.  But  If  you  achieve  portability  by 
using  special  numeric  types  that  aren't 
derived  fro*  Integer  or  float  to  get  the 
same  range  and  precision  on  any  computer 
(for  example,  an  array  of  digits),  you 
won't  be  able  to  instantiate  TFXT_TO 'a 
generic  packages  to  convert  those 
vnrisbles  to  ASCII  representations.  Then 
it  does  become  s  TFXT_10  problem. 

Confusing  Incon sjji te  11  cy 

Chapter  14  (which  describes  TEXT_IO)  is 
probably  the  moat  confusing,  inconsistent 
part  of  the  LRM.  When  talking  about  the 
Get  for  characters  it  says: 
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“After  skipping  any  line  terminators 
nmi  «ny  page  terminators,  (Get) 
read*  the  next  character  fro*  the 
specified  Input  file  And  returns  the 
vslue  of  this  character  In  the  out 
parameter  ITEM."  LRM  section  14.3.6 
paragraph  3 

this  says  that  every  line  terminator* 
no  matter  where  it  occurs*  Is  skipped. 

Now,  here  is  what  It  says  about  the  Get 
procedure  for  strings: 

“Determines  the  length  of  the  given 
string  and  Attempts  that  number  of 
GET  operations  for  successive 
characters  of  the  string  (In 
particular*  no  operation  is 
performed  If  the  string  Is  null).* 

LRM  section  14.3.6  paragraph  9 

This  implies  It  also  skips  all  line 
terminators*  because  It  calls  the  Get 
procedure  for  characters.  A  pattern  is 
beginning  to  take  shape.  Out  wait,  see 
what  it  says  about  integers  (or  real 
numbers) : 

“If  the  value  of  the  parameter  WIDTH 
is  sero*  skips  any  leading  blanks* 
line  terminators,  or  page 
terminators,  then  reads  a  plus  or 
minus  sign  If  present,  then  reads 
according  to  the  syntax  of  an 
integer  lor  "a  real")  literal  (which 
may  be  a  based  literal).  If  a 
nonsero  value  of  WIDTH  is  supplied, 
then  exactly  WIDTH  characters  are 
Input,  or  the  characters  (possibly 
none)  up  to  a  line  terminator, 
whichever  comes  first;  any  skipped 
leading  blanks  are  included  in  the 
count."  LRM  section  14.3.7  paragraph 
G  (or  14.3.8  paragraph  9) 

So  numeric  forms  of  Get  skip  leading 
line  terminators  only  if  WIDTH  is  zero, 
and  never  skip  a  terminator  that  appears 
after  a  character  of  any  kind  has  been 
encountered.  Since  integers  are  Just  a 
special  kind  of  enumeration  type,  you 
might  expect  enumeration  types  to  be 
similar.  They  aren't. 

“After  skipping  any  leading  blanks, 
line  terminators,  or  page 
terminators,  reads  an  identifier 
according  to  the  syntax  of  this 
lexical  element  (lower  or  upper  case 


equivalent),  or  a  character  literal 
according  to  the  syntax  of  this 
lexical  element  (including 
apostrophes).  Returns,  in  the 
parameter  ITEM,  the  value  of  type 
ENUM  that  corresponds  to  the 
sequence  Input."  LRM  section  14.3.9 
paragraph  6 

What  does  it  do  about  line 
terminators  encountered  after  a 
significant  character?  It  doesn't  say. 
Suppose  an  object  of  »  user-defined 
enumeration  type  can  have  the  values  HAND, 
AID,  RANDAID,  and  BANDMASTER.  How  does 
T KXTJQ  handle  “BAND«termlnator>AlO" , 
"BANDA ID" ,  and  "BAND<terminator>MASTER"?  I 
sure  don't  know. 

So  far,  the  specification  has  said, 
“Character  Gets  ignore  all  terminators; 
numeric  Gets  recognise  terminating 
terminators,  and  sometimes  ignore  leading 
terminators;  enumeration  gets  (other  than 
integer  Gets)  always  Ignore  leading 
terminators  and  might  not  recognise 
terminating  terminators."  Ah,  if  It  w«s 
only  that  simple.  But  there's  more. 

Since  *11  forms  of  Get  for  character 
data  types  Ignore  all  terminators,  we 
might  expect  Get_i/ne  (which  works  only 
for  strings  of  characters)  would  do  the 
same.  Not  so. 

"(Cet^G/ne)  Replaces  successive 
characters  or  the  apeciried  atrlng 
by  successive  characters  read  from 
the  specified  Input  file.  Reading 
stops  If  the  end  of  line  Is  met,  in 
which  case  the  procedure  SKIP„bINE 
is  then  called  (in  effect)  with  a 
spacing  or  one;  reading  also  stops 
If  the  end  of  string  Is  met. 

Characters  not  replaced  are  left 
undefined."  LRM  section  14.3.6 
parsgraph  13 

This  says  Gelatine  doesn't  ignore  any 
terminators  (including  leading  ones),  and 
skips  over  the  terminator  that  causes 
input  to  cease.  That's  surprising  because 

“The  character  or  line  terminator 
that  causes  input  to  cease  remains 
available  for  subsequent  input."  LRM 
section  14.3.6  paragraph  5 
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Is  this  a  contradiction?  Well,  the 
title  of  section  H.3.5  is  "Gel  and  Put 
Procedures* ,  so  presumably  the  discussion 
in  section  14.3.5  is  United  to  Gel  and 
Put  and  doesn't  apply  to  Cet.i/ne.  hut 
paragraphs  8  and  9  of  that  section 
specifically  deal  with  Se*mLlne  and 
G*l„Mr.e,  so  one  could  argue  that  the 
title  "Cet  and  Pul  Procedures"  is  a 
general  tern  that  Includes  all  output 
routines  (including  Ne*mMne)  and  all 
Input  routines  (including  6et_b/ne). 

Suppose  there  are  seven  characters 
before  a  line  terminator,  and  you  use 
G*l_Hne  to  fetch  a  “-character  string. 
Does  it  stop  reading  because  it  has  read 
seven  characters  (and  therefore  not  skip 
the  line  terminator)?  or  does  it  stop 
reading  because  there  are  no  more 
characters  on  the  line  (and  skip  the 
terminator)?  The  LRH  doesn't  say.  I 
expected  it  to  skip  the  line  terminator, 
but  found  it  didn't  on  two  vnlldaled 
compilers. 

fiesxft.U«UL5X8 t  ea 

It  Is  obvious  that  TEXT^IO  wts  designed 
for  files,  not  people.  Files  are  record- 
oriented,  and  people  are  character- 
oriented.  That's  why  the  Keyalroke_Coumer 
program,  shown  in  Figure  I,  won't  work. 


Figure  1.  A  program  plagued  with  problems. 

with  TEXT_IO;  use  TEXT_IO; 
procedure  Keystroke.Counter  is 
KEYSTROKE  :  character; 

COUNTER  :  integer; 

CONTROL_Z  :  constant  character 
:»  character' VAbt 26) ; 
begin 

put_llne("Prcs*  some  keys,  then" 
k  "  CONTROL-Z  to  quit."); 

COUNTER  :»  0; 
loop 

get (KEYSTROKE); 

exit  when  KEYSTROKE  *  CONTROL_Z; 
COUNTER  :*  COUNTER* 1 ; 
end  loop; 
new^line; 

put( "You  pressed"); 
putt  integer ' IMAGE(COUNTER) ) ; 
put_lin*("  keys."); 
end  Keystroke_Counter; 


If  someone  gave  you  the  Hating  of 
the  Keyairoke^Counter  and  naked  you  what 
it  does,  you  would  probably  say  that  it 
counts  the  number  keys  pressed  before  the 
user  presses  CONTROb.Z,  then  prints  the 
number  of  keys  pressed.  That's  what  it 
appears  to  do,  but  it  doesn't. 

The  first  problem  is  the  CONTROb.Z. 
That's  a  special  character  that  the 
operating  system  might  filter  out.  It 
might  be  ignored,  or  it  might  cause  the 
word  EXIT  to  be  printed  on  your  screen  (in 
reverse  video)  and  immediately  terminate 
your  program.  Since  CONTROU.Z  is  likely  to 
be  the  end-of-file  terminator,  TEXT^IO 
might  notice  that  the  CONTROb.Z  isn’t 
immediately  preceded  by  a  page  terminator, 
and  raise  EXPmERROR. 

Suppose  you  try  to  avoid  the  problem 
by  changing  the  exit  line  to  exit  when 
KEYSTROKE  «  It  still  won't  work. 

Suppose  you  type  three  characters  and  then 
a  period.  The  characters  are  echoed  as  you 
enter  them.  You  type  seven  more 
characters,  and  then  hit  the  carriage 
return.  Suddenly  it  prints  You  Pressed  3 
keys.  That's  because  the  operating  system 
is  treating  the  terminal  like  a  record- 
oriented  file.  It  waits  for  the  end  of 
record  before  it  passes  the  complete 
string  to  the  Keyatrokc^Counter.  Then 
Keyairoke^Counler  examines  the  siring  one 
character  at  a  time. 

You  might  think  you  can  solve  the 
problem  by  changing  the  exit  line  to  exit 
when  EEYSTROKE  -  ASCII. CR;  .  Wrong  again. 
TEXT^IO  was  designed  to  work  with  files. 
Files  don't  care  about  line  terminators. 
They  aren't  limited  to  an  8.5  inch  wide 
page,  so  they  don't  care  how  many 
characters  are  on  a  line.  As  far  as  they 
are  concerned,  line  terminators  are  just 
meaningless  symbols  sprinkled  about  in  the 
real  data  for  cosmetic  reasons,  so  the 
text  will  look  nice  on  a  printed  page. 

Remember,  the  character  Get  procedure 
ignores  ail  terminators  and  throws  them 
disdainfully  on  the  ground.  As  we  have 
already  noted,  the  LRM  doesn't  specify 
what  a  line  terminator  is,  but  all  the 
cospilers  I  have  used  happened  to  pick  the 
carriage  return.  So,  if  you  try  to  use 
get( KEYSTROKE)  to  get  a  series  of 
characters  until  a  carriage  return  is 
entered,  your  program  will  never  see  the 
carriage  return  because  it  is  discarded  as 
a  meaningless  line  terminator. 
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The  simplest  (but  not  the  beet)  volution 
is  to  find  n  unique  volution  to  ouch 
unique  problem.  Consider  the  TEXT^lO^Qulrk 
program  in  Figure  2.  It  is  a  nonsensical) 
contrived  example  to  show  what  happens 
when  you  read  two  integers  and  a  string. 
(It  doesn't  do  anything  with  X  or  Y,  and 
doesn't  check  to  see  if  the  user  entered  a 
response  in  lower  case.) 


Figure  2.  A  surprising  quirk  in  TEXT_IO. 

with  TEXT_JQ; 

procedure  TEXTJWJiulrk  is 

package  IST_IO  is  new 

TEXT„IO. INTEGEK_lO( integer) ; 
use  TEXT_IO,  1NT_I0; 

X,  V  :  integer; 

RES POSSE  :  string ( 1 . . 3 ) ; 

LENGTH  :  natural; 

DONE  :  boolean; 

begin 

new_llne; 

DONE  :«  FALSE; 
while  not  DONE  loop 

put( “Enter  X:  ");  get(X);  ncw_llne; 
put( “Enter  Y:  ");  get(Y);  new_line; 
put( “Do  you  want  to  do  it  again?” 

A  "  (YES  /  NO)  “); 
getjLinetHESPONSE,  LENGTH); 
if  KESPONSEt 1 . . 3 )  «  "YES"  then 
DONE  :«  TRUE; 
end  IT; 
end  loop; 

end  TEXT_IOJ)ulrk; 


If  you  compile  and  run  the  program, 
you  will  see  that  it  prompts  you  Vo  enter 
the  Integer  X.  After  you  enter  a  value,  it 
prompts  for  Y.  When  you  enter  Y,  it 
responds  with  both  the  prompts  for  YES/NO 
and  X.  It  acts  as  if  you  entered  a  blank 
line  instead  of  YES  or  NO.  Since  a  blank 
line  is  not  YES,  it  goes  back  to  the  top 
of  the  loop. 


Why  did  it  do  this?  After  processing 
GetiX),  the  line  terminator  was  still 
“available  for  subsequent  input”  as 
section  14.3.5(5)  requires.  The  G*t(Y) 
procedure  skipped  it  and  read  your  second 
integer  entry,  stopping  Just  before  the 
line  terminator.  Then  £?et„L/ne  read  the 
line  termlnctor  associated  with  the  entry 
of  Y  and  thought  you  entered  a  null 
response  to  the  question  about  whether  to 
do  the  loop  again  or  not.  HESPOSSEU .  .3  } 
contained  unspecified  characters,  and 
LESGTH  had  the  value  0,  so  it  wasn't  equal 
to  YES.  DOXE  remained  EAl.SE  and  it  w«nl  to 
the  top  of  the  loop  again.  The  solution  to 
the  problem  is  to  add  a  Skip,  Lin* 
immediately  after  CtlfYJ.  This  gets  past 
the  line  terminator  so  G«*t„L/ne  will  wait 
for  you  to  enter  a  response. 

Notice  1  have  called  S«*_Line 
following  each  Get.  That's  because  I 
expect  Get  to  recognise  the  carriage 
return  and  throw  it  away  without  echoing 
it.  X  tried  TEXT^IO^Quirk  on  two  different 
Ada  compilers.  On  one,  that’a  exactly  what 
happened.  The  prompt  to  input  Y  was  on  the 
line  immediately  below  the  Input  X  prompt 
because  it  did  not  echo  the  <CRXLF> 
sequence.  On  the  other,  there  was  a  blank 
line  between  the  two  prompts  because  it 
did  echo  the  <CRXLF>.  The  spec  doesn't 
say  which  is  correct,  ao  both  are  correct, 
if  I  had  left  the  A'ew.Une  calls  out,  then 
one  machine  would  display  prompts  on 
adjacent  lines,  hut  the  other  machine 
would  overlap  the  prompts. 

When  porting  a  program  from  one 
computer  to  another,  you  may  find  that  you 
have  to  add  (or  delete)  Ncv^Llne  calls 
after  every  Get  and  Get_Linc.  If  you  want 
to  Pat,  Get,  Put,  and  Get,  all  on  the  same 
line,  some  implementations  of  TEXT^IO  will 
prevent  you  from  doing  that  because  the 
carriage  return  that  terminates  the  first 
Get  will  be  automatically  echoed. 

Both  machines  acted  the  same  when  I 
entered  a  blank  line  in  response  t(  the 
input  .V  prompt.  They  ignored  the  carriage 
return  internally,  and  continued  to  wait 
for  me  to  enter  .V  without  raising  an 
exception.  What  surprised  me  was  that  both 
echoed  the  <CRXLF>  sequence. 

Other 

I  hope  you  agree  that  Ad  Hoc  solutions 
like  the  one  shown  above  aren't  a  very 
good  idea.  Every  time  you  port  a  program, 
you’ll  have  to  tweek  on  it  vc 
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make  it  work.  There's  got  to  be  a  better 
way.  I  think  the  better  way  is  to  not  try 
to  uae  TEXT^IO  as  a  user  interface.  It 
wasn't  designed  to  be  a  user  interface, 
doesn’t  have  enough  capability,  and  it 
isn't  consistently  implemented. 

Remember,  Ada  doesn't  require  you  to 
use  rar.W.  TEXT_IO  is  Just  another 
feature  that  you  can  chose  to  use  if  you 
like.  1  don't  like.  Instend,  I  wrote  ay 
own  set  of  user  Interfaces,  these  packages 
are  called  VIRTUAL_TERHINAL, 

SCROLL_TERH INAL ,  and  FORH^TERHINAL.  A 
complete  description  of  these  user 
interface  packages  (with  source  code)  is 

in  In-AsMan « 2 

VIRTVAL_TERHINAL 

Terminals  are  notoriously  inconsistent 
when  it  comes  to  control  codes.  They  all 
have  different  control  sequences  for 
clearing  the  screen  and  moving  the  cursor. 
The  VIRTVALJIERHINAL  hides  all  these 
differences.  It  can  be  used  for  screen- 
oriented  displays.  It  is  handy  whenever 
you  want  to  move  the  cursor  all  over  the 
screen  and  write  text  fragments  in 
different  places,  but  that  isn't  its  main 
use.  The  VIRTUAL_TF.RMINAL  is  most  valuable 
as  a  foundation  for  other  terminal 
packages,  such  as  SCROLI.JTERNINAL  and 
FORH_T£RHINAL.  Those  two  packages  are 
built  entirely  on  top  of  VIRTUAL_TERNINAL, 
with  no  system-dependent  calls,  so  it 
isn’t  necessary  to  have  different  bodies 
for  every  Implementation.  If  you  can  write 
a  VIRTUALJTERHINAL  body  that  works  with  a 
different  physical  terminal  or  different 
operating  system,  then  you  can  port 
SCROLl_TERMINAL  and  FORH_TF.RHIXAL  without 
any  modifications. 

SCROLL_TERHINA L 

SCROLL_TERNINAL  is  TEXT_IO  redesigned  for 
users  instead  of  files.  It  contains 
familiar  subprograms  like  Get ,  Get_Line, 
Put,  Put_Line,  Set_Col,  and  so  on.  The 
difference  between  it  and  TEXT_IO  is  that 
it  supports  line  editing  consistently, 
offers  defaults,  allows  the  user  to  enter 
invisible  data,  and  has  built-in 
NEEDS_HELP  and  PANIC  exceptions.  It  never 
echoes  the  terminating  carriage  return, 
regardless  of  the  host  operating  system, 
so  you  can  confidently  follow  every  Get 
with  a  Neu_Line  if  you  want  the 


next  prompt  to  appear  on  the  next  line. 
{Vou  can  leave  out  the  AVw_bi/ie  if  you 
want  the  next  prompt  to  appear  on  the  same 
line.)  It  is  good  for  user  dialogs,  where 
questions  must  be  asked  and  answered  in  a 
specific  order. 

FORN.TERHINAL 

FQRH.TERHISAL  is  radically  different.  It 
has  the  same  editing  features  and 
NEEOS_HF.LP  and  PANIC  exceptions  that 
SCROl. TERHINA L  has,  but  the  similarity 
stops  there.  FORS_TERSINAL  rills  the 
screen  with  questions,  default  responses, 
and  spaces  for  user  inputs.  The  user  can 
Jump  around  the  screen,  entering  data  in 
any  order.  The  user  can  even  go  back  to 
previous  screens  if  necessary.  You  could 
write  a  spreadsheet  program  using  the 
FORH^, TERHINA L .  (Try  doing  that  with 
TEXT_IO.  ) 


I’ve  had  only  minor  trouble  with  TEXT^IO 
as  a  file  interface.  Sooner  or  later, 
though,  I'm  afraid  TEXT_IO  could  cause 
some  major  problems.  Just  to  be  on  the 
safe  side,  I'm  working  on  a  package  called 
ASCII^IO  that  is  a  portable  version  of 
TEXT_IO.  It  has  the  same  features  as 
TEXT_IO,  but  it  operates  exactly  the  same 
on  all  operating  systems.  Initial 
experiments  with  ASCII^IG  show  that  it 
solves  the  problems  I've  talked  about 
here,  but  it  creates  a  whole  new  set  of 
problems.  Sse  the  March/April  'R9  Ada  Info 
column1  for  a  discussion  of  those 
problems. 

TJjai-F.9-r_Uylng_JgA'I-fO 

I  use  TEXT_IO  in  simple  example  programs 
when  I  don’t  want  irrelevant  10  questions 
to  distract  from  the  point  of  the  example. 
For  real  programs,  however,  I  never  use 
TEXT_IO  for  a  user  interface,  and  I'm 
working  on  a  better  text  file  interface. 

My  first  tip  is: 

(1)  Don't  use  TEXT  TO  if  vou  c an  avoid  it. 

If  you  take  that  advice,  you  don't 
need  any  more  tips.  However,  if  you  are 
stuck  with  TEXT_I0,  here  are  some  more 
helpful  suggestions. 
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You  *mw  the  trouble  you  cun  net  Into  when 
you  mix  Get  and  Gel^Line  In  Figure  1.  You 
avoid  this  If  you  always  use  Get.LI/ie  to 
read  characters  into  a  text  airing  that  la 
longer  than  the  longest  possible  input 
string.  This  limits  you  to  one  value  on  a 
line,  which  costa  a  little  overhead  (extra 
<CRXLF>  sequences),  but  if  you  were 
worried  about  file  size  you  would  be  using 
binary  files  instead  of  ASCII  files.  I 
like  one  value  per  line  because  it  makes 
it  easy  to  examine  the  file  (characters 
don't  fall  off  the  side  of  a  printed 
listing)  and  it  is  easy  to  find  the  value 
of  a  specific  variable  (the  Nth  variable 
is  on  the  Ntli  line). 

l9£^°idL£*>IL_^xJ-aMrS„.. 

Suppose  you  have  a  variable  called 
PROTECTED  that  can  TRUE  or  FALSE,  and  you 
need  to  store  this  variable  in  a  file. 
People  commonly  instantiate  ENUMERATION 
_JfO.  I  don't  like  that  solution.  It  forces 
you  to  use  Get  instead  of  Get  Line, 
because  ENUHERA TIOS_ JOdoesn't  have  a 
Get_Line.  Here's  an  alternative: 

—  save  a  boolean  variable  in  a  file 

put.line 

( FILE , boolean ' IMAGE( PROTECTED ) ) ; 

—  read  a  boolean  variable  back  from 

—  a  file  (TEXT' LENGTH  >  5) 

get_line( FILE,  TEXT,  LENGTH); 

PROTECTED  ;r 

boolean'VALUE(TEXT(l. .LENGTH) ); 

—  raises  CONSTRAINT_ERROR  for 

—  strings  other  than  TRUE  or  FALSE 

Suppose  you  print  a  file  containing 
many  boolean  variables.  It  will  be  full  of 
the  words  TRUE  and  FALSE.  It  may  not  be 
clear  which  variables  are  TRUE  and  which 
are  FALSE  simply  by  looking  at  the  file. 
That's  why  I  prefer  to  do  it  this  way: 


—  save  a  boolean  variable 
if  PROTECTED  then 

put_li net  FILE, “PROTECTED" ) ; 
else 

put_llnc( FILE, "UNPROTECTED" ) ; 
end  if; 

—  read  it  back  ( TEXT ' LENGTH  >  11) 
gct.l ine( FILE, TEXT,  LENGTH); 

if  TEXTH..3)  «  "PRO"  then 
PROTECTED  :«  TRUE; 
els  if  TEXTU..3)  »  "UNP"  then 
PROTECTED  :■  FALSE; 
else 

raise  CONSTRAINT_ERROR; 
end  if; 

tJiQX 

iat£isr_10i 

You  don't  to  have  Instantiate  IN1EGER_I0 
to  input  or  output  integers.  You  can  use 
the  IMAGE  and  VALUE  attributes  to  read  and 
write  corresponding  text  strings. 

--  save  an  Integer  variable  in  a  file 
put.) Inc  ( FILE, integer' IMAGE(X ) ) ; 

—  read  an  integer  variable  back  from 
--  a  file 

get.li ne{ FILE,  TEXT,  LENGTH); 

X  :«  lnteger’VALUE(TEXT(l.. LENGTH)); 

—  may  raise  CONSTRAINT.ERROR 

LS-L-V* g.  P <LJ>J.u.<L-fu 0 9tJ 0 P •-f  or _R C S .1 

Ada  doesn't  have  IMAGE  and  VALUE 
attributes  for  variables  of  type  float, 
but  you  can  write  Imnge  and  Vtlue 
functions  that  do  conversions  between  real 
numbers  and  character  strings.  I've  done 
that  already  myself.  The  source  code  for 
those  functions  is  in  the  ASGII^UTILITIES 
package  in  Ada  in  Action.1 

Conclusion 

TEXT_IO  tries  to  be  both  a  file  interface 
and  a  user  interface,  and  it  does  neither 
job  very  well.  It  is  loosely  specified, 
presumably  to  make  it  compatible  with  a 
variety  of  underlying  operating  systems, 
and  this  leads  to  portability  problems.  It 
is  adequate  for  trivial  programs,  but  Just 
won't  do  the  job  for  programs  with  an 
extensive  user  interface,  or  programs  that 
have  to  share  text  files  on  a  variety  of 
different  machines. 
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One  solution  would  be  to  nuke  massive 
changes  to  Chapter  14  of  the  LRH.  That's 
not  a  good  idea  because  the  revision  of 
HIL-STD-1815A  will  take  a  long  time,  and 
significant  changes  to  Chapter  14  will 
Just  delay  the  approval  even  more.  Some 
vendors  will  cry  "foul"  because  it  will  be 
more  difficult  to  Implement  the  new 
TEXT^IO  on  their  operating  systems  than 
their  competitors,  and  they  will  try  to 
prevent  approval. 

Fortunately,  isn't  necessary  to 
change  the  LRH.  It  doesn't  say  you  have  to 
use  TEXT_IO  for  all  10.  You  can  simply 
ignore  TEXT_JO  and  use  something  else  for 
the  user  interface.  If  TE.VT_.TO  causes 
compatibility  problems,  use  a  different 
file  Interface  package.  You  can  write  your 
own  10  packages,  or  use  packages  published 
in  the  open  literature. 
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Automatic  Test  Data  Generation  and  Assertion  Testing 
for  Ada  Program  Units 
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Under  the  auspices  of  the  Software  Technol - 
<ogy  for  Adaptable,  Reliable  Systems  (STARS) 
Foundations  program,  Intermetrics  Inc. 
developed  a  tool  to  support  the  testing  of  Ada 
program  units.  The  tool,  called  the  Ada  Test 
Support  Tool  ( TST ),  is  a  compiler  inde¬ 
pendent,  portable  tool  used  for  testing  sub¬ 
programs  and  task  entry  points  within 
compilable  Ada  units.  TST  supports  the 
automated  testing  of  Ada  program  units,  al¬ 
lows  assertions  to  be  made  about  test  results, 
documents  test  results,  and  provides  for 
regression  testing.  This  paper  describes  TST 
and  experiences  gained  in  the  development 
and  use  of  the  tool. 


INTRODUCTION 

As  the  demand  for  highly  reliable  software 
systems  grows,  software  testing 
methodologies  and  tools  become  increasingly 
important.  New  testing  methodologies,  like 
those  described  in  [GclHis],  which  focus  on 
preventative  software  testing  throughout  the 
life-cycle  show  promise  in  meeting  these 
demands.  The  Ada  Test  Support  Tool  (TST) 
developed  by  Intcrmctrics  can  be  used  to 
automate  some  of  the  activities  required  in  a 
life-cycle  testing  approach. 


TST  is  a  dynamic  analysis,  compiler  inde¬ 
pendent  tool  written  in  Ada  to  test  Ada  sub¬ 
programs  and  tasks,  collectively  termed 
routines  for  this  paper.  TST  generates  Con¬ 
trol  Programs  that  contain  calls  to  visible 
routines  in  Ada  units.  Users  invoke  the  Con¬ 
trol  Program  and  supply  input  parameters  or 
request  "testdata  generation"  for  routines  they 
choose  to  test.  Assertions  may  be  made  about 
output  values  to  specify  the  expected  result  of 
tests.  Input  parameters  and  test  results  arc  out¬ 
put  to  a  TST  report. 

This  paper  describes  TST  and  the  lessons  we 
learned  while  developing  the  tool.  Topics 
presented  include:  Ada  as  a  development  lan¬ 
guage,  experiences  in  reusing  software,  most 
useful  application  of  TST,  problems  wit,  the 
tool,  and  future  directions. 

BACKGROUND 

TST  leverages  on  technology  developed  for 
the  Ada  Test  and  Analysis  Tools  (ATEST)  In¬ 
tcrmctrics  built  for  the  WIS  (WWMCCS  In¬ 
formation  Systems)  program.  The  ATEST 
tools,  documented  in  [Inter],  include  a  perfor¬ 
mance  analyzer,  path  analyzer,  variable  trace 
tool  and  a  symbolic  debugger;  all  of  the  tools 
use  dynamic  analysis  techniques  to  monitor 
programs  as  they  are  executing.  The  perfor¬ 
mance  analyzer  measures  execution  speed  and 
the  path  analyzer  records  the  statements  and 
subprograms  executed  during  the  run  of  a 
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program.  The  variable  trace  tool  records  the 
values  of  program  variables  during  execution 
of  a  program  and  the  symbolic  debugger  al¬ 
lows  programmers  to  step  through  a 
program’s  execution  and  change  the  value  of 
program  variables  at  the  source  code  level. 

The  unique  aspect  of  the  ATEST  tools  is  that 
they  are  not  dependent  on  a  specific  Ada  com¬ 
pilation  system.  The  system  independent  na¬ 
ture  of  the  tools  is  accomplished  using  a 
Source  Instrumcntcrthatparscs  Ada  programs 
and  embeds  additional  code  in  the  source 
code.  This  code  provides  "hooks"  to  a  Run 
Time  Monitor  that  is  used  to  record  program 
execution  information.  TST  uses  a  modified 
version  of  the  symbolic  debugger's  Source  In- 
strumcntcr. 

In  1987,  the  STARS  (Software  Technology 
for  Adaptable  Reliable  Systems)  Foundations 
program  contracted  a  variety  of  tools  targeted 
to  Ada  software  development,  with  the  inten¬ 
tion  of  promoting  a  "software  first"  software 
development  strategy  described  in  [STARS]. 
"Software  first"  refers  to  developing  software 
incrementally  and  deferring  hardware  choices 
to  later  phases  in  the  development  process. 
The  Foundations  tools  were  required  to  be 
highly  portable  for  easy  integration  into 
software  development  environments  that  are 
being  built  under  the  STARS  Competing 
Primes  program.  Intcrmctrics  proposed  TST 
in  two  phases.  In  Phase  I,  a  basic  testing 
capability  was  provided,  and  for  Phase  II, 
automatic  test  data  generation  and  assertions 
were  added. 

PREPARING  A  UNIT  FOR  TESTING 

Figure  1  illustrates  how  users  generate  TST 
Control  Programs.  At  the  top  of  the  figure,  a 
computer  terminal  shows  the  commands 
which  the  user  enters.  The  three-dimensional 


boxes  in  ihe  figure  represent  executable 
programs.  The  Shell  and  Source  Instrumcntcr 
are  provided  by  TST,  the  Compiler  and  Linker 
are  provided  by  the  user,  and  the  Control 
Program  is  generated  by  TST.  Each  of  these 
programs  may  be  separately  executed  at  the 
system  level  with  Ada  procedure  calls  or  from 
within  the  Shell.  The  Shell  provides  a  help 
facility,  prompts  for  parameters  when 
programs  arc  invoked,  and  allows  users  to  set 
TST  system  variables  (c.g.,  report  width  and 
length,  screen  echo  flag). 

First,  the  user  invokes  the  Source  In- 
strumenter  which  generates  a  Control 
Program  and  inserts  "hooks"  into  the  source 
code  so  that  the  Run  Time  Monitor  can  gain 
control  during  program  execution.  The  unit 
to  be  tested  needs  to  be  instrumented  along 
with  any  units  declaring  types  that  are  used  by 
the  unit  being  tested.  For  example,  in  Figure 
2  the  procedure  UNIQUE_FILENAME  in 
package  FILENAME  has  a  parameter  of  type 
SYSTEMJDEPENDENCIES.FILENAME. 
In  order  to  test  the  FILENAME  package,  both 
the  SYSTEM_DEPENDENCIES  and 
FILENAME  packages  must  be  instrumented. 


The  Source  Instrumenter  adds  code  to  the 
unit’s  body  for  tracing  statements  but  makes 
no  changes  to  the  specification.  A  support 
package  which  provides  routines  to  read, 
write,  get  the  next  value,  and  compare  values 
is  generated  for  each  visible  Ada  type  decla¬ 
ration.  In  addition,  a  Control  Program  which 
has  calls  to  all  routines  visible  in  the  unit  to  be 
tested  is  generated.  The  support  package,  the 
Control  Program,  and  the  body  of  the  unit 
being  instrumented  arc  copied  into  a  file 
which  is  named  by  appending  the  extension 
".INS"  to  the  body  file  name. 
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TJT>  SI  (fMwrm.td*) 
TST>  S*(Sr **>.»*•) 
TST>  CotSywN^ln*) 
TST>  Co(fl*n»m*.ln») 
TST>  LM(TST  rd*n«n«) 
TST>  Bur  (TST./»«w**) 


C0MP1CB 


CONTROL 

PROGRAM 


ln»:/um*n!*d 


Ad* 

Soutc* 

Ffc* 


Figure  1.  Creating  i 


udth  SYSTEM_OEPENOENClES; 
p*ck*g*  FILENAME  i* 
procedure  UNIQUE  FILENAME  ( 

.  NAME :  out  SYSTEM_D£PEND£NCCS.FIENAME); 


•od  FILENAME; 

Figure  2.  Both  the  Tested  Unit  and  Depen¬ 
dent  Unit  Need  To  Be  Instrumented. 

After  all  units  have  been  instrumented,  the 
compiler  is  invoked.  Any  compiler  may  be 
used,  as  long  as  the  TST  installation  process 
has  been  completed  for  that  compiler.  Inter- 
metrics  has  hosted  TST  on  the  Alsys  PC/AT, 
Alsys  Sun,  and  the  DEC  Ada  compilers. 


Control  Program. 

When  all  units  have  been  compiled,  the  linker 
is  invoked  to  produce  an  executable  Control 
Program.  The  main  program  input  to  the 
linker  is  the  Control  Program  generated 
during  instrumentation.  The  Support 
Program,  Control  Program,  specification  of 
the  unit  being  tested,  any  dependent  units,  and 
the  units  comprising  the  Run  Time  Monitor 
are  linked  to  create  an  executable  Control 
Program.  The  Run  Time  Monitor  units  must 
be  compiled  prior  to  linking;  this  is  done  once 
when  TST  is  installed  and  docs  not  have  to 
repeated  each  time  an  executable  Control 
Program  is  created. 
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TESTING  A  UNIT 

After  the  executable  Control  Program  is 
created,  testing  may  begin.  When  the  Control 
Program  is  executed  from  the  Shell  or  at  the 
system  level,  a  Testing  Subsystem  user  inter¬ 
face  is  displayed.  A  TST  system  variable 
specifics  whether  or  not  the  Testing  Subsys¬ 
tem  is  in  full  screen  or  line  mode.  For  line 
mo  ’c,  only  the  Testing  Subsystem  prompt, 
"T>"  is  displayed.  If  the  terminal  supports  full 
screen  mode,  then  a  dual  window  Testing 
Subsystem  is  displayed.  The  upper  window 
lists  testable  routines  and  assertions,  and  the 
lower  window  is  used  for  interaction  between 
TST  and  the  user.  Figure  3  illustrates  the  full 
screen  Testing  Subsystem  for  an  Exchange 
package  which  contains  two  procedures  for 
swapping  integer  and  string  values. 


Figure  3.  The  Testing  Subsystem  Displays 
Testable  Routines  and  Prompt  for  Input 

While  in  the  Testing  Subsystem,  users  may 
call  routines,  make  assertions,  generate  test 
data  and  invoke  the  help  facility  by  using  Test¬ 
ing  Subsystem  commands.  Table  1  lists  and 
describes  each  command. 

As  shown  in  Figure  3,  the  user  is  prompted  for 
some  information  about  the  test.  The  user  is 
first  prompted  for  a  textual  description  of  the 


Table  1.  Commands  Are  Used  To  Get  User 
Input. 


COMMAND 


DESCRIPTION 


ASSCnnON.HANOONO  (ACTION) 
CALL.ROUTINE  (ROUTINEJO) 
0€LETE_0l.0eAL  (ASSERTIONJD) 
DEt.ETE_l.OCAt.  (ASSERTION  10) 
DISPLAY.  ASSERTIONS 
DOWN(NUM_lWE$) 

END 

GL06AL.ASSERT  (ASSERTION) 
HELP(TOPIC) 

LIST_ROUTINES 

LOCAL. ASSER’  (ASSERTION) 

UP  (NUMJ.WES) 

YANOOW  (WSPLAY_WINOOW_SeE) 


S«t  Mtwiion  talur*  action 
Cal  amain*  to  M 
0*M*  a  global  aaaartbn 
DtWt*  a  local  a— nfrn 
LlK  axr-rt  a*»*rtion» 
ScioldownNUM.UNES 
Ouk  lb*  Tatting  Subayatotn 
Mat*  a  global  aaawPon 
OatMptora  command 
Uat  routinwlnuna 
MaM  a  local  a***rtbn 
Sad  up  NUMJ.MES 
Raabt  upper  dndow 


test  session.  This  description  may  be  used  to 
identify  and  track  tests.  The  Test  Data  File  is 
the  name  of  an  ASCII  text  file  that  will  be  used 
to  record  commands  input  by  the  user  during 
the  testing  session.  If  the  Test  Data  File 
entered  already  exists,  then  the  user  will  be 
prompted  to  cither  use  that  file  as  test  input  or 
tooverwrite  the  file  with  new  commands.  The 
Test  Data  File  provides  a  convenient  means 
for  repeating  tests  (regression  testing). 

If  a  Test  Data  File  was  specified  as  input,  then 
the  commands  in  the  file  will  be  run  without 
user  interaction.  Otherwise  the  "T>"  prompt 
is  displayed  and  the  user  may  start  entering 
commands.  The  commands  of  the  most  sig¬ 
nificance  are  CALL_ROUTINE, 
GLOBAL_ASSERT,  and  LOCAL_AS- 
SERT.  Each  of  these  commands  is  described 
below.  The  Exchange  package  shown  in 
Figure  3  is  used  as  an  example  for  the  descrip¬ 
tions.  In  the  examples,  TST  prompts  arc  in¬ 
dented  and  user  input  is  in  boldface  type. 

The  CALL_ROUTINE  command  allows  the 
user  to  specify  test  cases  for  a  routine.  For  ex¬ 
ample,  if  the  user  issues  the  command: 
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T>  CALL_ROUTINE  1 

for  the  Exchange  package,  then  the  system 
will  echo  the  name  of  the  routine  and  wait  for 
the  user  to  enter  parameter  values: 

T>  CALL_ROUTINE  1 

SWAP  (_ 

The  user  then  enters  literal  values  for  the  test 
and  test  results  arc  echoed  to  the  screen: 

T>  CALL_ROUTINE  1 

SWAP  (4, 6); 

PI  =  6 

P2  =  4 

T> 

or  generates  test  data: 

T  >CALL_ROUTINE  1 
SWAP  (5,  *1); 


Input  Data: 
PI  =5 
P2  = -32768 
PI  =-32768 
P2  =  5 


Input  Data: 


PI  -  5 
P2»0 
PI  =0 
P2-5 


Input  Data: 

PI  =5 
P2 »  32767 
PI =  32767 
P2  =  5 
T> 

Test  data  generation  is  accomplished  through 
the  use  of  the  **'  symbol.  If  is  entered, 
then  every  possible  value  for  that  type  will  be 
generated.  If  ’*X’  is  entered,  where  X  is  a 
natural  number,  then  the  set  of  possible  values 
for  the  type  will  be  partitioned  into  X  subsets, 
and  the  first,  middle,  and  last  values  for  each 
of  the  subsets  will  be  generated.  All  permuta¬ 
tions  of  parameter  values  will  be  generated. 
Figure  4  illustrates  the  permutations  generated 
for  an  enumerated  type. 

Another  feature  available  in  TST  is  assertions. 
By  using  the  GLOBAL_ASSERT  and 
LOCAL_ASSERT  commands,  the  user  can 
specify  conditional  statements  about  output 
parameters  and  function  results.  For  example, 
for  the  Exchange  package,  the  following 
assertions  could  be  made: 

T>GLOBAL_ASSERT  1,  PI  <10 
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Global  Assertion  1)  1,  Pi  <10 

T>LOCAL_ASSERT  1,  P2  >5 

Local  Assertion  2)  1,  P2  >5 

where  the  first  number  in  the  command  repre¬ 
sents  the  routine  to  which  the  assertion  applies 
and  the  following  input  is  a  conditional  state¬ 
ment  about  an  output  value.  In  this  case  we 
have  made  a  global  assertion  about  the  integer 
Swap  procedure  that  states  that  the  value  of 
parameter  PI  should  be  less  than  10.  The 
local  assertion  states  that  for  the  integer  Swap 
procedure,  parameter  P2  should  be  greater 
than  5.  The  example  below  shows  how  asser¬ 
tions  fail. 

T>CALL_ROUTINE  1 
SWAP(5, 3); 

PI  =  3 


P2  =  5 


assertion  did  not  fail  for  the  second  call  be¬ 
cause  local  assertions  are  valid  only  for  the 
next  CALL_ROUTINE  command.  Global 
assertions  are  valid  until  the  testing  session 
ends  or  the  assertion  is  deleted  using  the 
DELETE_GLOBAL  command.  Current 
assertions  may  be  displayed  in  the  upper  win¬ 
dow  of  the  Testing  Subsystem  using  the  DIS¬ 
PLAY,,  ASSERTIONS  command. 


K  A  Package  Hat  The  Declaration*: 

typa  COLOR  it  (RED,  BLUE.  GREEN,  YELLOW.  BROWN); 

procedure  SWAP  (Cl :  in  out  COLOR.  C2 :  in  out  COLOR); 

And  The  Following  Command  It  Invoked  In  The 
Tatting  Subtyttem 
T>  C  1 


SWAP  (\M) 

Then  Swap  Writ  Automatically  Be  Caled  With  Each  Of  The 


Following  Input  Valuet: 

SWAP  (RED.  RED) 

SWAP  (RED.  GREEN) 
SWAP  (RED.  BROWN) 
SWAP  (BLUE.  RED) 
SWAP  (BLUE.  GREEN) 
SWAP  (BLUE.  BROWN) 
SWAP  (GREEN.  RED) 
SWAP  (GREEN.  GREEN) 
SWAP  (GREEN.  BROWN) 


SWAP  (YELLOW.  RED) 
SWAP  (YELLOW.  GREEN) 
SWAP  (YELLOW.  BROWN) 
SWAP  (BROWN.  RED) 
SWAP  (BROWN.  GREEN) 
SWAP  (BROWN.  BROWN) 


***  Local  Assert  2)  1,  P2  >  5  Failed 
T>CALL_ROlITINE  1 
SWAP(6, 11); 

PI  =  11 
P2  =  6 

***  Global  Assert  1)1,  PI  <10  Failed 
T> 

In  the  first  call  the  local  assertion  failed  be¬ 
cause  the  value  of  P2  was  less  than  5.  In  the 
second  call  the  global  assertion  failed  because 
the  value  of  PI  was  greater  than  10.  The  local 


Figure  4.  All  Permutations  of  Parameter 
Values  Are  Generated. 

Assertions  provide  the  user  with  a  mechanism 
for  stating  the  expected  values  of  output  data. 
When  the  expected  results  arc  not  attained,  the 
user  is  warned  by  a  failed  assertion.  This  is  an 
important  concept  in  that  the  user  is  explicit¬ 
ly  warned  and  the  warning  is  put  into  a  report 
for  later  review.  Failed  assertions  indicate 
that  a  test  did  not  proceed  successfully. 
Assertions  are  especially  valuable  for  creating 
test  cases  using  Test  Data  Files  in  a  text  editor. 
Test  Data  Files  that  include  assertions  about 
expected  test  results  can  be  written  early  on  in 
the  software  development  life-cycle  and  are 
useful  for  discovering  problems  in  software 
designs. 
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DOCUMENTATION  OF  TEST 
RESULTS 

After  the  user  has  completed  a  test  session,  a 
collection  of  reports  describing  the  results  is 
generated.  The  Configuration  Report  lists  in¬ 
formation  about  the  time,  date,  executable 


Control  Program  name,  and  default  TST  sys¬ 
tem  parameters.  The  Routine  Report  lists  the 
testable  routines  that  were  displayed  in  the 
upper  window  of  the  Testing  Subsystem.  The 
Parameter  Report  lists  the  routines  that  were 
called,  results  of  tests,  assertions  made,  and 
failed  assertions.  Figure  5  shows  a  Parameter 


Unit  Under  Teat:  (  1) 

procedure  SWAM 

PI  :  In  cue  INTEGER; 

?2  :  in  out  INTEGER); 

Parameter  Entering  Value  Exiting  Value 


FI  4  C 

P2  4  4 


Unit  Under  Teat:  (  1) 

procedure  SNAP ( 

Pi  :  in  out  INTEGER; 
P2  :  in  out  INTEGER); 


Teat  Data  Automatically  Generated 
P2  ->  *1 


Parameter 

Entering  Value 

Exiting  Value 

FI 

5 

-32741 

F2 

-32741 

5 

PI 

5 

0 

F2 

0 

5 

FI 

5 

32747 

F2 

32747 

5 

GLOBAL  Aaaertion 

1)  1,  pi  <  10 

leeamaaaaMaeeaaMeeeiaiM 

LOCAL  Aaaertion 
Unit  Under  Teat: 

procedure  SWAP ( 
PI  :  in  out 
P2  :  in  out 

Parameter 

2)  1,  p2  >  5 
t  1) 

INTEGER; 

INTEGER) ; 

Entering  Value 

Exiting  Value 

PI 

S 

3 

P2 

3 

5 

*••  LOCAL  Aaaertion  2)  1,  P2  >  5  railed 

LOCAL  Aaaertion 
Unit  Under  Teat: 

2)  1,  P2  >  5  Deleted 

(  1) 

procedure  SNAP  ( 

PI  :  in  out  INTEGER; 

F2  :  in  out  INTEGER); 

Parameter  Entering  Value  Exiting  Value 


FI  6  11 

F2  11  ( 

•••  GLOBAL  Aaaertion  1)  1,  PI  <  10  railed 


Figure  5.  The  Parameter  Report  Lists  Test  Results. 
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Report  corresponding  to  the  example  given  in 
the  text  above. 


The  Execution  History  Report  consists  of  two 
parts.  The  first  report  lists  the  order  that 
routines  were  entered,  resumed,  or  ended.  Ex¬ 
ceptions  are  also  shown  in  this  report  if  they 
were  not  handled  by  the  originating  routine. 
The  second  report  enumerates  the  number  of 
times  that  statements  or  groups  of  statements 
were  executed.  A  listing  file  that  maps  state¬ 
ments  to  the  numbers  shown  in  the  Execution 
History  Report  is  produced  by  the  Source  In- 
strumcntcr.  Figure  6  shows  an  example  Ex¬ 
ecution  History  Report  for  the  example  above. 


Begin  EXCHANGE . SWAP 
(1-4] 

End  EXCHANGE. SWAP 

Begin  EXCHANGE . SWAP 
[1-4] 

End  EXCHANGE. SWAP 

Begin  EXCHANGE. SWAP 
11-4] 

End  EXCHANGE. SWAP 

Bogin  EXCHANGE. SWAP 
tl-4] 

End  EXCHANGE. SWAP 

Begin  EXCHANGE. SWAP 
tl-4] 

End  EXCHANGE. SWAP 

Bogin  EXCHANGE. SWAP 
tl-4] 

End  EXCHANGE. SWAP 

Statement  Execution  Count 


EXCHANGE 

d-4]  6 

(5-8]  0 


Figure  6.  The  Execution  History  Report 
Shows  Routines  and  Statements  Executed. 


The  Execution  History  Report  is  useful  for  en¬ 
suring  that  all  routines  and  statements  were 
executed. 


The  Test  Data  File  generated  while  the  test 
was  proceeding  may  also  be  examined  for 
determining  test  coverage.  The  Test  Data  File 
is  in  ASCI!  format,  includes  comments,  and 
may  be  modified  or  created  by  the  user.  The 
Test  Data  File  created  in  the  test  session  above 
is  shown  in  Figure  7. 


■  •  i  i 

—  i.«) 

call  routine  i  « 

Fl  «>  ■< 

FI  *>  6 
U 

...  c  l 

— •  5.  •» 

CALL  ROUTINE  l  I 
Fl  «»  5 
pj  »>  -3:n« 

); 

CALL  ROUTINE  l  ( 

PI  •>  5 
P2  •>  0 
); 

CALL  ROUTINE  l  ( 

PI  ->  5 
P2  ->  32167 
); 

ASSERTION  HANDLING  COntinut 
CL08AL  ASSERTION  l.  PI  <  10 
local  Assertion  i,  P2  >5 

—  c"l 

—  5.3) 

CALL  ROUTINE  1  ( 

PI  «>  5 
P2  »>  3 
); 

— •  c  l 

—  •  6,11) 

CALL  KUTINE  1  ( 

PI  »>  6 
P2  •>  11 
); 

Figure  7.  The  Test  Data  File  May  Be  Viewed 
And  Modified. 


RECOMMENDED  APPLICATIONS  OF 
TST 


Using  test  data  generation  and  assertion  han¬ 
dling  features,  we  have  found  that  TST  is  a 
good  tool  for  specifying  tests  when  designing 
and  during  the  final  stages  of  coding  an  Ada 
unit.  Some  recommendations  about  using 
TST  arc  listed  below: 
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Routines  that  are  encapsulated  and  have 
well-defined  inputs  and  outputs  arc  the  best 
candidates  for  testing  with  TST. 

One  of  the  most  promising  application  areas 
for  TST  is  in  testing  reusable  software  com¬ 
ponents  that  have  well-specified  outputs. 
As  software  reuse  becomes  more  widely  ac¬ 
cepted  and  practiced,  it  will  become  in¬ 
creasingly  important  to  prove  the 
correctness  of  the  reusable  software.  Con¬ 
versely,  reuse  is  promoted  when  program¬ 
mer  confidence  is  increased  because  it  is 
easier  to  test  and  grater  test  coverage  is  en¬ 
sured.  TST  allows  programmers  to  easily 
create  new  test  cases  for  software  on  the 
compiler  that  will  be  used  for  development 
and  delivery,  thus  improving  theconfidence 
in  reusable  software  that  is  ported  to  dif¬ 
ferent  machines  and  compilation  systems. 

TST  could  be  used  as  a  debugging  tool,  but 
this  is  not  recommended  because  compile 
times  are  increased  because  of  the  support 
package  and  Control  Programs  that  the 
Source  Instrumcntcr  generates. 

Because  TST  focuses  on  the  inputs  and  out¬ 
puts  of  routines,  those  routines  that  modify 
global  data  and  do  not  return  values  cannot 
be  adequately  tested  with  TST. 

Components  that,  are  highly  user  interac¬ 
tive,  like  menu  generators  and  screen  gen¬ 
erators  could  be  tested  quite  easily  when  the 
user  is  present  to  view  the  output  on  the  dis¬ 
play  device. 

To  provide  thorough  testing,  TST  should  be 
used  in  the  context  of  an  integrated  test  plan. 


PROBLEMS  WITH  TST  (AND 
POSSIBLE  SOLUTIONS) 

We  have  found  that  a  significant  amount  of 
code  is  generated  during  instrumentation  for 
test  data  generation.  During  instrumentation, 
a  support  package  that  includes  routines  for 
reading,  writing,  getting  the  next  value,  and 
doing  comparisons  for  assertions  arc 
generated  for  each  visible  type  in  a  package 
specification.  Tabic  2  lists  the  lines  of  code 
generated  for  the  different  types.  Packages 
containing  many  types,  especially  complex 
user-defined  types,  could  result  in  very  large 
support  packages. 

Table  2.  Code  Added  When  Instrumenting. 


twbN. 

Assertions 
stm  lines 

Test  Data 

Generation 
stm  lines 

Read/ 
Writ* 
stm  line* 

Predefined 

0 

0 

0 

0 

0 

0 

Enumirillon, 

FkMfoe  a 

Ffied  Point 

1 

1 

2 

10 

2 

2 

Ace* m 

35 

19 

19 

39 

24 

51 

Array 

constrained 

3S 

72 

•  I 

1(2 

21 

59 

unconstrained 

122  227 

3( 

71 

Record 

no  discriminant 

39 

72 

91 

110 

25 

55 

discriminated 

155  300 

40 

7S 

s  !m:  Adi  statements 

lines:  lin«*  ot  cod*  (Includes  comma.,  is  and  Wank  tpeces) 

In  addition,  Control  Programs  are  generated 
for  each  unit  and  a  small  amount  of  code  is 
added  at  the  beginning  and  end  of  each 
routine.  The  size  of  Control  Programs  is  de¬ 
pendent  on  the  number  of  routines  defined  in 
the  unit  being  tested  and  the  number  and  type 
of  parameters  within  each  routine. 

A  significant  amount  of  the  generated  code 
may  never  be  used.  For  example,  package  A 
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may  use  one  type  declared  in  package  B  which 
has  ten  additional  types  defined.  Package  B 
must  be  instrumented  in  order  to  test  package 
A  and  code  will  be  generated  for  alt  of  the 
types  in  package  B  because  when  B  is  instru¬ 
mented  wc  do  not  know  which  types  A  will 
need. 

While  a  good  Ada  linker  will  remove  this 
"dead"  code,  the  problem  of  compiling  the  ad¬ 
ditional  code  is  not  alleviated.  A  possible 
solution  to  this  problem  would  be  to  provide 
a  post-instrument  tool  that  allows  the  user  to 
specify  which  unit  they  plan  to  test.  The  tool 
could  go  through  the  source  instrumented 
code  for  package  B  and  comment  out  the  code 
added  for  the  types  that  are  not  needed  along 
with  the  Control  Program,  if  any,  created  for 
B. 

Another  problem  is  the  technique  used  for  test 
data  generation.  Very  large  test  inputs  will 
result  for  routines  having  many  parameters 
which  have  a  large  range  of  possible  values. 
Using  the  partition  method  of  lest  data  genera¬ 
tion  (i.e.,  *X)  alleviates  this  problem  some¬ 
what,  but  does  not  allow  complete  test 
coverage.  Wc  have  considered  adding  the 
ability  to  generate  values  within  a  specified 
range,  but  even  this  technique  may  produce 
more  data  than  is  needed.  These  problems 
point  out  the  fact  that  at  the  present  time,  tools 
cannot  bear  the  full  burden  of  testing;  intel¬ 
ligent  selection  of  test  input  must  be  provided. 

Currently  TST  has  no  facility  to  do  configura¬ 
tion  control  on  the  testing  of  many  units.  A 
test  manager  tool  could  be  provided  to  inform 
the  user  when  a  unit  has  been  changed  and 
needs  to  be  re-tested.  A  tool  that  lists  the  units 
that  need  to  be  instrumented  to  test  a  particular 
unit  would  also  be  beneficial. 


Additional  reports  could  be  generated  that 
show  thoroughness  of  testing  for  each  routine. 
A  tool  that  allows  testing  of  routines  within 
the  body  of  units  would  also  be  useful.  This 
could  be  accomplished  by  putting  the  Control 
Program  in  the  body  of  the  package  being 
tested  and  adding  code  for  all  types  declared 
in  the  body. 

ADA  AS  A  DEVELOPMENT 
LANGUAGE 

Similar  tools  (Dcutsch)  have  been  created  for 
testing  programs  written  in  other  languages. 
One  of  the  problems  wc  encountered  develop¬ 
ing  the  tool  in  Ada  was  the  inability  to  gel 
"into"  the  code  because  of  scoping  ties  and 
strong  typing.  For  example,  private  and 
limited  private  types  cannot  be  tested  because 
Ada  does  not  allow  the  examination  of  private 
data  outside  of  the  unit's  body.  Wc  also  en¬ 
countered  problems  due  to  the  rich  typing 
provided  by  Ada.  Test  data  generation  for  the 
vast  number  of  types  that  may  be  constructed 
and  complex  types  like  multi-dimensional  un¬ 
constrained  arrays  and  variant  records  was 
especially  challenging. 

Because  Ada  is  well  suited  to  reuse,  we  were 
able  to  build  TST  in  a  relatively  short  period 
of  time.  Table  3  shows  the  amount  of  code 
developed  and  reused  and  person-months  re¬ 
quired  to  compete  the  tool.  User’s  guides, 
presentations,  and  design  reviews  are  in¬ 
cluded  in  the  person-month  estimates. 

Wc  had  the  added  advantage  of  programmers 
who  knew  Ada  when  the  project  started,  and 
some  who  had  worked  on  the  original  WIS 
tools  that  formed  the  basis  of  TST. 
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Table  3.  Significant  Productivity  Increase* 
May  Be  Achieved  When  Software  Is  Reused. 


CODE 

OEUVERED 

$2,500  IOC 

REUSED 

OCCE 

45.000  IOC 

PERSON MONTHS 

34.5 

PRODUCTIVITY 
WITH  REUSE 

1811.5  LOOP*r*on 
Month 

PRODUCTIVITY 

NOTNCIUOWG 

REUSE 

1304.3  LOC/Porson 
Month 

Our  experience  in  reusing  software  resulted  in 
the  following  conclusions. 

•  Software  designed  using  object-oriented 
techniques  is  easier  to  understand  and  reuse. 

•  Adequately  commented  code  is  important, 
but  not  critical  in  reuse.  Code  that  performs 
a  well-understood  function,  is  well 
designed,  uses  meaningful  variable  names, 
and  is  not  extremely  complex  can  be  under¬ 
stood  by  experienced  Ada  programmers 
even  if  it  is  not  well  documented. 

•  Isolation  of  system  dependent  features 
makes  porting  reusable  software  almost 
pain-free. 

During  development  of  TST,  we  were  pleased 
with  the  state  of  Ada  compilers.  Most  of  the 
development  for  TST  was  done  on  C/AT 
clones  using  the  Alsys  compiler.  A  few 
problems  concerning  data  size  were  en¬ 
countered,  but  these  were  expected.  We  also 
had  some  problems  with  tasking  and  our 
program  libraries,  but  these  were  corrected 
with  compiler  updates. 


CONCLUSION 

Tools  supporting  software  testing  are  impor¬ 
tant  in  achieving  the  level  of  reliability  re¬ 
quired  for  today’s  complex  software  systems. 
However,  testing  tools  must  be  integrated  in  a 
complete  software  test  plan  that  spans  the  life¬ 
cycle.  We  have  outlined  a  tool  that  supports 
testing  in  a  small  area,  and  have  given  sugges¬ 
tions  for  improving  the  tool.  U  is  the  opinion 
of  the  authors  that  TST  and  other  test  tools  will 
not  become  widely  accepted  until  industry  un¬ 
derstands  the  benefits  that  testing  can  bring  to 
both  software  design  and  verification. 
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ABSTRACT 

Packaging  schemes  can  negatively  impact  a 
system's  performance  and  maintainability. 
Adherence  to  a  design  methodology  and  good 
soltwaro  engineering  are  no1  always  sulllclont  to 
ensure  optimum  system  performance.  This  paper 
suggests  guidelines  to  be  followed  to  avoid  or 
correct  the  problems  of  code  copy  Instantiation, 
linking,  and  recompilation.  Four  areas  are  covered; 
generics;  packaging;  Interfaces  to  non-Ada  code; 
and.  recompilation  requirements. 

Packaging  schemes  can  negatively  Impact  a 
system's  performance  and  maintainability.  Herein 
are  suggested  guidelines  to  minimize  this  kind  of 
Impact.  Those  guidelines  are  based  upon 
experiences  encountered  in  building  two  large 
Interactive  applications  Involving  many  thousands  of 
lines  of  Ada  code. 

Tho  design  of  the  software  architecture  can  be 
as  Important  to  the  success  and  acceptance  of  a 
system  as  the  design  of  the  logic.  More  than  any 
other  programming  language.  Ada  requires  a 
software  engineer  to  consider  the  physical 
arrangement  and  placement  of  program  units. 
Program  units,  data  types,  and  data  objects  must  be 
grouped  Into  packages. 

How  packages  are  organized  relates  directly  to 
how  the  finished  system  will  perform  and  how  easily 
K  can  be  maintained.  True,  the  design  methodology 
must  be  the  primary  authority  for  packaging 
schemes.  Within  this  framework,  however, 
consideration  also  must  be  given  to  compiler  and 
linker  behaviors  and  Ada  recompilation  issues. 

Idiosyncrasies  In  compilers  and  linkers  make  it 
difficult  to  predict  how  an  Ada  system  will  behave 
when  It  Is  finally  ported  to  the  target  machine.  These 
behavior  differences  often  can  be  a  factor  in  the 
system's  success.  Hence  the  notion  that  system 
destgn  can  be  completed  without  regard  for  the 
supporting  hardware  and  operating  system 
environment  Is  fundamentally  false.  Ada  designs  will 
be  Independent  of  hardware  considerations  only 
when  compilers  and  linkers  are  mature  enough  to 
eliminate  the  code-copy  method  of  Instantiation  at  id 
the  philosophy  of  “link  in  everything.”  i 


The  present  state  of  the  art  Is  such  that  the 
approach  a  compiler/linker  takos  to  generic 
Instantiation  or  packaged  modules  can  make  a 
critical  difference  In  tho  deliverable  system. 
Consequently,  knowing  how  the  linker  and  compiler 
work  does  and  should  affect  how  the  Ada  software 
architecture  Is  designed.  Moreover,  that  architecture 
should  take  recompilation  effects  into  consideration, 
particularly  In  large  systems  where  the  recompilation 
time  may  be  measured  in  days. 

We  will  focus  our  attention  on  four  major 
problom  areas,  and  recommend  counter  measures 
that  will  provide  developers  with  a  degree  of 
protection  from  unpredictable  or  unacceptable 
results.  The  four  areas  are:  1)  generics,  2) 
packaging,  3)  Interfaces  to  non-Ada  code,  and  4) 
recompilation  requirements. 

Compilers  that  Implement  each  generic 
Instantiation  as  a  separate  code  copy  can  cause 
tremendous  overhead  In  the  final  Image  size.  Each 
Instantiation  of  the  same  package  causes  a  new 
complete  copy  of  tho  original  generic,  with  values 
for  Its  generic  parameters,  to  be  generated.  The 
guidelines  presented  here  are  Intended  to  minimize 
the  potential  code  explosion. 

Linkers  generally  link  In  all  of  a  package 
whether  It  Is  actually  used  by  the  application  or  not. 
When  unnecessary  code  and  data  are  linked  Into 
the  final  image,  memory  is  wasted:  virtual  memory 
systems  experience  Increased  page  faulting, 
resulting  In  performance  degradation.  The 
consequences  of  the  link  everything  philosophy  are 
far  reaching,  particularly  in  the  area  of  reusability. 
We  will  discuss  packaging  schemes  that  are 
designed  to  minimize  any  excess  baggage. 

The  designers  of  the  Ada  language  realized  that 
the  transition  from  other  languages  would  be 
gradual  ano  that  entire  libraries  of  proven 
subroutines  would  have  to  be  accessible  from  Ada 
In  order  lor  the  language  to  reach  acceptance  by 
the  engineering  communky.  However,  Indiscriminate 
use  ol  Pragma  INTERFACE  may  involve  penalties 
when  you  try  to  convert  those  subroutines  to  Ada. 
We  will  offer  some  suggestions  for  keeping  those 
penalties  to  a  minimum. 
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Ada  recompilation  requirements,  enforced  by 
DoD-STD"l815A,  can  be  costly  In  large  system 
development;  It  may  take  days  to  recompile  a 
system.  Many  times  these  compilations  are 
unnecessary,  such  as  when  an  additional 
enumeration  value  was  added  to  a  type  definition. 
Incremental  compilation  Is  not  widely  available.  We 
will  demonstrate  that  a  packaging  strategy  can 
protect  against  extensive  recompilation. 

Generics 

Much  of  the  problem  associated  with  gonorics 
actually  occurs  In  Instantiations.  As  mentioned 
before,  Ada  compilers  have  implemented 
instantiation  by  copying  the  entire  generic  unit  and 
substituting  the  actual  generic  parameters  for  the 
formal  generic  parameters  and  then  compiling  this 
code.  Given  this,  how  can  we  minimize  the  size 
Issues  raised  by  creating  multiple  copies  of  the 
generic  unit? 

Package  AH  Generic  instantiations 

Lacking  rules  to  the  contrary,  packago 
developers  will  instantiate  a  generic  directly  In  the 
package.  If  two  package  dovelopors  ncod  the  same 
generic,  each  will  Instantiate  it.  If  they  happen  to  be 
using  the  same  parameters,  two  identical 
Instantiations  of  the  generic  are  In  the  system.  It  Is 
difficult  to  identify  this  waste  because  these 
Instantiations  are  hidden  in  package  bodies,  In 
accordance  with  the  dictates  of  encapsulation. 

The  simplest  and  cleanest  way  to  handlo  this 
problem  Is  to  create  a  packago  specification  lor  the 
Instantiation  and  then  use  rename  and  subtyping  to 
make  the  necessary  Instantiated  units  and  data 
types  visible.  Now  the  generic  packago  is 
Instantiated  only  once:  only  ono  copy  of  the  code  is 
made. 

To  Illustrate  this.  Example  1  Is  a  commonly 
used  generic  specification  for  a  linked  list.  Example 
2  is  a  package  that  encapsulates  an  instantiation  of 
this  yenoric.  With  this  resource  available,  package 
developers  may  make  as  many  uses  of  the  linked 
list  as  is  necessary  without  inadvertently  creating 
multiple  Instantiations. 


Include  Only  the  Necessary  in  a  Generic 

Generic  unit  bodies  frequently  contain 
supporting  program  units  that  do  not  depend  on  a 
generic  parameter.  There  is  nothing  at  all  generic 
about  these  program  units,  but  they  contribute  to  the 
functionality  of  the  generic  package  and  hence  are 
included  in  the  package  body.  Of  course,  at 
Instantiation,  the  compiler  creates  copies  of  these 
units  as  well  as  those  that  are  truly  generic  since 


they  ate  contained  In  the  same  package  body. 
Place  those  supporting  units  In  thoir  own  package 
and  reference  the  package  from  tho  generic  unit. 
The  unnecessary  code  duplication  is  avoided.  This 
problem  is  frequently  encountered  in  generic  units 
that  are  paramotorlzod  by  generic  procoduros 
and/or  functions  only.  All  such  generic  package 
body  routlnos  should  be  oxamlnod  to  see  If  thoy  can 
be  moved  Into  a  packago  of  their  own.  Example  3 
illustrates  such  a  packago. 

generic 

type  USTJTEM  Is  pfivato; 
packago  UNKEDJJST  is 

lypa  LIST_TYPE_ACCESS  Is  limiiod  prfvaio: 

procedure  INSERT  AT  HEAD 

(QUEUE  fin  our  LISTTYP£_ACCESS; 

ITEM  :  in  USTJTEM): 

procodure  INSERT  AT  TAIL 

(QUEUE  :  In  out  LIST_TYPE_ACCESS: 

ITEM  :  In  USTJTEM): 

procoduro  REMOVE  JFROM  HEAD 

(QUEUE  :  in  out  USTTYP£_ACCESS: 

ITEM  :  out  USTJTEM): 

procoduro  REMOVE  FROM  TAIL 

(QUEUE  :  in  out  LISTTYPE_ACCESS: 

ITEM  :  out  USTJTEM); 

private 

typo  USTTYPE: 

typo  UST_TYP£_ACCESS  Is  accoss  USTTYPE: 

typo  USTJYPE  Is 
record 

INFO  :  USTJTEM: 

NEXT  :  Usf_TYPE_ACCESS  null: 

PREV  :  LIST~TYPE_ACCESS  :■  null; 
end  record: 
ond  UNKEDJJST: 

Exempt*  1 

Centric  Linked  List  Ptckagt  Specification 


Packaging 

As  discussed  earlior,  linkers  link  tho  entire 
context  of  a  program  unit  without  regard  for  what  Is 
actually  necessary  to  the  execution  of  tho  program. 
Many  extraneous  data  objects  and  program  units 
are  Included  in  images  this  way. 

Object  Oriented  Design  (OOD)  Is  a 
methodology  that  Is  frequently  associated  with  Ada, 
primarily  because  of  Ada's  powerful  capabilities  to 
encapsulate  and  abstract  data  and  procedures.2  if 
you  subscribe  to  an  OOD  methodology,  then  your 
package  specifications  contain  all  of  the  object 
definitions  and  actions  normally  associated  with  the 
object.  Take  as  an  example  th9  management  of  a 
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*i!h  UNKEOJ.IST; 

p«ckag«  ITEMJ.IST  ia 

lypfl  ITEM_7YFE  It  ; 

p»ck*0«  ITEMJUNKEOJJST  is  now  Uf.KED_t.lST 
(UStjtem~*>  rr£w_TYPE); 

tubtyp*  UST_TY PE _ACCE SS  is 
ITEM  JJMKEOJJST.UST_TYPE,  ACCESS: 
procedure  INSERT  ATJIEAD 
(QUEUE  :  In  out 

IT£M_UNKED_UST.UST_7YP£_ACC£SS: 
ITEM  :  In  ITEMJIYPE) 

renames  ITEM_UNXED_UST.INSERT_AT_H£AO; 
procedure  INSERT  AT  TAU. 

(QUEUE  :  In  out 

lT£M_UNKEO_UST.USTTi'P£_ACCnSS: 
ITEM  1  In  IT£M_TYP£) 

renames  ITEM_LINKED_UST.INSERT_AT_TA!L; 
procedure  REMOVE  FROM  HEAD 
(QUEUE  :  In  out  ” 

ITEM_UNXEO_UST.UST_TYP£_ACCESS: 
ITEM  "  oulTlEMJTYPE) 

renames  ITEM_UNKEO_UST.REMOVE_FROM_HEAD: 
procedure  REMOVE  FROM  TAR. 

(QUEUE  :  in  out  “ 

ITEM_UNKEO_UST.UST_TYPE_ACCESS; 
ITEM  :  out  ITEMJTYPE) 
renames  ITEM_UNKED_UST.REMOVE_FROM_TAR.: 
end  ITEMJJST; 

Example  2 

Pa c*epe  Specification  o /  an  Intlinilnion  o I  It i# 
Ganarfc  Unktd  Usl  In  Eximpl*  I.  Subiyplng  and 
Ptntmlng  Hava  Bean  Used  tor  Visibility 


dictionary.  An  object  is  read  from,  written  to,  or 
deleted  from  the  dictionary.  According  to  OOD,  a 
package  (or  packages)  should  exist  that  specifies 
the  object  definition  and  this  set  of  actions.  We  will 
assume  for  purposes  of  this  example  that  these  are 
contained  in  a  single  package,  as  In  Example  4. 

As  long  as  each  program  using  this  package 
needs  the  read/write/delete  functions,  the  package 
design  offers  no  problems.  But  suppose  another 
program  in  the  system  only  needs  to  read  items 
from  the  dictionary.  Because  the  package  was 
designed  as  a  single  entity,  this  second  program 
must  carry  the  code  to  perform  the  other  functions 
as  well.  Not  only  Is  there  extra  code  included  In  the 
Image,  but  there  is  the  potential  that  functions  other 
than  read  are  being  performed.  Referencing  a  unit 
makes  it  potentially  callable.  From  a  quality 
assurance  perspective,  there  is  no  guarantee  that 
this  program  does  not  delete  or  write  to  the 
dictionary  In  some  way. 


with  UNIT_D€FIN1TI0N:  use  UNlT_DEFlNITlON: 
generic 

with  procedure  PROCESS 
(UNIT  tin  UN1T_TYPE): 

pecMje  PROCESS  UNITS  l* 
procedure  PROCESS  UNIT 

(UNIT  TO  PROCESS  t  In  UNIT  TYPE); 
end  PROCESS JJN1TS: 

peekege  body  PROCESSJJNITS  1* 

—This  function  is  not  dependent  on  any  generic  parameter 
—and  its  such  It  can  and  should  be  removed  lo  its  own 
—supporting  package. 

tunc  ion  UNIT  IS  PROCESSAQLE 

(UNIT  :  in  UNIT  TYPE)  roturn  BOOLEAN  Is 
begin  —  UNlT_lS_PROCESSABLE 

end  UN!T_lS_PROCESSABl.E: 

procedure  PROCESS  UNIT 

(unit_to_proce5s  :  m  unittypei  is 

begin  —  PROCESS  UNITS 

if  UNIT  IS  PROClSSABLE  (UNIT  TO  PROCESS)  then 
PROCESS  (UNIT  ■>  UNIT  T&_PROCESS): 
end  II; 

end  PROCESSJJNIT: 
end  PROCESSJJNIT; 


Examp/e  3 

Examo/e  o I  Generfc  Package  Body  With  non-Generfc 
Parameter  Dependent  Progrtm  Unlit 


The  solution  Is  to  break  up  the  original  package 
Into  smaller  units  and  use  the  subsystem  approach 
(Example  5),  although  this  does  have  a  tendency  to 
multiply  the  number  of  packages  in  a  software 
system.  The  example  should  be  Implemented  as 
multiple  packages:  1)  Data  Definitions.  2) 
Read-Only,  3)  Write,  4)  Delete.  (In  some  cases  it 
might  be  acceptable  to  combine  the  Write  and 
Delete  procedures  In  one  package.) 

Of  cours3,  the  original  program  should  be  tvblo 
to  view  this  object  and  its  associated  actions  as  a 
single  entity.  So,  a  fifth  package  specification  Is 
created  which  references  the  ether  four  and  uses 
rename  and  subtyping  to  transfer  visibility 
(Example  6). 

This  technique  does  not  work  for  generic 
packages,  we  should  note.  Using  the  linked  list  In 
Example  1.  if  a  program  needed  to  traverse  the  list 
going  forward  and  backward,  two  more  procedures 
would  have  to  be  added  to  the  package 
specification.  This  has  been  done  In  Example  7. 
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peckege  ITEM  DICTIONARIES  is 
type  OCTK5NARYJTEM  Is 
record 

end  record; 

lype  DtCTJO_TYPE  Is  ...  ; 

procedure  WRITE 

(DICTION ARY  IDENTIFIER 
ITEM 

procedure  READ 

(DICTIONARY  IDENTIFIER 
ITEM  :  in 

procedure  OELETE 

(DICTIONARY  IDENTIFIER 
ITEM 

:  In  DICT  O  TYPE; 

:  in  OlCTiONARYJTEM): 

:  in  DICT  ID  TYPE: 
out  DICTION ARYJTEM): 

:  In  DICT  ID  TYPE: 

:  m  OCTfbNARYJTEM): 

end  ITEM_DICTIONAn!ES: 

Example  4 

Package  Speculation  Illustrating  Object  end  Actions 

This  change  requires  all  other  users  of  the 
generic  package  to  recompile,  and  Imposes  the 
necessity  to  carry  around  the  two  traverse  routines. 
There  is  no  elegant  solution.  Because  the  unit  Is 
generic  and  generic  units  cannot  instantiate  other 
generic  units  based  upon  their  own  generic 
parameter  values,  this  package  cannot  bo  broken 
l-o  smaller  dependent  packages.  A  tradeol!  must 
be  made  with  regard  to  (Inal  Image  size  and  ultimate 
maintainability.  It  the  etteci  on  Image  size  is  critical, 
the  only  alternative  Is  to  have  two  packages  that 
manage  linked  lists,  one  with  tho  traversing  routines 
and  one  without. 

Slruclured  Design,  Practices  Suwoil 

Architectural  Changes 

We  have  found  many  times  that  adhering  to 
principles  of  good  structured  dosign  can  help  to 
overcome  problems  in  the  architecture.  In  the 
following  actual  situation,  the  minimal  cohesion 
between  program  units  In  a  package  that  had  grown 
too  large  made  subdividing  the  package  a  small 
chore.  Not  a  single  unit  body  was  modifiod.  and  the 
pared  program  ran  through  Its  lest  suite  flawlessly 
the  first  time. 

We  were  able  to  reduce  the  Imago  of  an  Ada 
program  by  fifty  percent  by  re-packaging  some  of 
the  units  originally  written  for  another  program  within 
the  same  project.  Entire  trees  of  unused,  but 
referenced,  program  units  were  eliminated  by 
re-packaging.  The  original  size  of  the  program  was 
1012  blocks  (512  bytes/biock),  but  after  careful 
study  of  the  reused  code  to  determine  which  units 
were  being  unnecessarily  Included  In  the  program 
closure,  and  re-packaging  to  eliminate  numerous 
packages,  the  image  size  was  reduced  to  443 
blocks!  This  also  reduced  the  image  load  time,  and 
page  faults  were  decreased  by  thirty-three  percent. 


peeks g«  rTEM_DtCTiONARy_OATA_C£FS  is 

type  DiCTtONARYJTEM  » 
record 


end  rocord: 

type  DK5TJOJTYPE  is  ...  ; 
end  ITEM_OSCTIONAnYJ>ATA_DEFS: 

with  ITEM  DICTIONARY  0ATA  DEES: 
use  IT  £  M  DON  ARY  ”0  AT  A  *CE  F  S : 

peekago  ITEM_DtCT10NARY_READ  Is 
procedure  READ 

(DICTIONARY  ID  :  m  D*CT  K3  TYPE: 
ITEM  “  :  in  out  DiCTloNARYJTEM); 

end  ITEM_OiC'nONARY_READ: 

wish  ITEM  DICTIONARY  DATA  DEFS: 
use  !TEM_diCTi0Nary_0ata’defS: 

pecks  go  IT  E  M_DtCTlON  ARY_WR!T E  Is 
procedure  WRITE 

(DICTIONARY  ID  :  In  DICT  ID  TYPE: 

ITEM  :  In  DiCTiONARYJTEM); 

end  rTEM_D)CTIONARY_wniTE: 

with  ITEM  DICTIONARY  DATA  DEFS: 
use  ITEMJCICTIONARY'DATAJJEFS: 

package  ITEM_DICTiONARY_OELETE  is 
procedure  DELETE 

(O’-CTtCNARY  ID  :  In  DICT  ID  TYPE: 

ITEM  :  m  DICTIONARY JTEM) ; 

end  ITEM_niCTIONARY_DELETE; 


Example  S 

Package  o I  Example  4  Subdivided  Into  Smeller  Vote 
Reusable  Components 


Interfaces  to  Non-Ada  Code 

Existing  libraries  of  non-Ada  code  are  ofton 
useful  in  Ada  applications.  Some  Ada  applications 
may  require  a  portion  of  the  system  to  bo 
implemented  In  another  language  (e.g.,  Assembler) 
in  order  to  meet  requirements  of  timing.  For  those 
and  other  reasons,  it  Is  often  necessary  for  Ada 
programs  to  coexist  with  other  source  language 
solutions. 

In  order  to  refer  to  non-Ada  modules  from  an 
Ada  program.  Ada  requires  an  Interface  definition, 
including  a  “pragma  INTERFACE."  These  can  be 
expressed  wherever  they  are  needed,  but  tho 
specter  of  maintenance  difficulties  Is  introduced. 
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with  ITEM  OCTKXARY  DATA  OEFS: 
with  ITEM  DICTIONARY  RE AO~ 

With  ITEM  DICTIONARY  WRITE; 

With  ITEM_OICTiONARY.OEl.ETC; 

pAC**5«  TTEM.CiCTlCNARY  Is 

subtype  OCTfONARY  ITEM  is 
R£M_05CTK>NAAY_&ATA_DEF$,OiCT10NARY_REM; 

proeeduftt  READ 

(DICTIONARY  ID  :  in  DtCTJO  TYPE; 

ITEM  ;  «  out  C-CTsCNARYJTEM) 

(tirwmos  ITEM_OiCTiONARY.REAO.READ: 

ptOCWJoto  V.IttTE 

(DCTJONARY  ti)  ;  in  OtCT  10  TYPE: 

ITEM  :  in  OCTtONARYJTOM) 

ronsmes  TTEM.OCTtONARY.WftSTE -WRITE : 

ptocoduta  DELETE 

(OCTCNARY  10  :  m  OCT  10  TYPE: 

ITEM  :  in  OCTCNARY  ITEM) 

ronamos  REM.OCTIONARY.OSLETE  .DELETE : 

and  rTEM.OCTCNARY; 


Example  6 

&ng!e  Package  Specification  Created 
From  it)*  Pockapas  In  Example  $ 


How.  (or  example,  can  thoso  definitions  bo  located 
when  ono  ol  thoso  modules  Is  to  bo  rowritlon  In 
Ada? 


alaJLho.Jatarf.acQS 

Treat  all  non-Ada  modules  as  “foreign" 
package  bodies  by  defining  thoir  own  package 
specifications.  By  putting  the  intortaco  definitions  in 
their  own  spcciticadon.  the  problem  ol  multiple 
definitions  lor  a  slnglo  routine  is  avoldod.  Since 
thero  Is  a  "slnglo  source"  (or  the  routine, 
maintenance  Is  simplified. 

II  you  do  not  package  the  specifications  lor  a 
non-Ada  Interlace,  thon  In  order  to  Implement  that 
modulo  In  Ada.  you  must  strip  out  tho  interlace 
definitions,  and  roplace  them  with  the  now  routlno 
by  modifying  tho  original  package  and.  perhaps, 
producing  an  additional  one.  By  defining  the 
interface  as  a  package  specification,  you  will  simply 
remove  the  "pragma  INTERFACE"  Irom  the 
package  specification,  add  a  package  body,  and 
recompile.  No  other  unit  need  be  modified. 

(Incidentally,  here  Is  an  examplo  of 
unnecessary  recompilation  being  required  by  Ada. 
Removal  ol  tho  pragma  INTERFACE  should  not 
cause  obsoloscenco  ot  units  referencing  this 
package  specification.) 


g«no(fc 

type  USTJTEM  is  pNvato: 

pacXao«  UNKED_U5T_WITH_TnAVERSE  IS 

type  UST  TYPE  ACCESS  Is  Fm-tod  privat*: 
procod uro  INSERT  AT  HEAD 

(QUEUE  :  In  out  USTJYPE.ACCESS: 

ITEM  :  in  USTJTEM); 

procedure  INSERT  AT  TAIL 

(QUEUE  :  In  out  USTTYPE.ACCESS: 

REM  ;  in  USTJTEM): 

procedure  REMOVE.FROM  HEAD 

(QUEUE  :  In  out  USTJYPE.ACCESS: 
REM  :  out  LISTJTEM): 

procedure  REMOVE  FROM  tail 

(QUEUE  :  in  out  "  USTJYPE.ACCESS; 
REM  :  out  USTJTEM): 
procedure  TRAVERSE  FQRWARO 

(QUEUE  :  in  USTJYPE.ACCESS: 
REM  :  out  USTJTEM; 

C0NTEX7  :  in  oul  USTJYPE.ACCESS): 

procedure  TRAVERSE  BACKWARD 

(QUEUE  “in  LIST.TYPE.ACCESS: 
REM  :  out  LIST. REM; 

CONTEXT  :  in  out  USTJYPE.ACCESS): 

private 

type  UST. TYPE; 

type  LIST.TYPE.ACCESS  Is  eccoss  L1STJYPE: 

type  LISTJYPE  Is 
record 

INFO  :  UST.REM; 

NEXT  :  LIST.TYPE.ACCESS  :•  null: 

PREV  •  UST.TYPE ^ACCESS  ;■  null: 
end  record: 

end  UNKED.UST.WITHJRAVERSE: 

Example  7 

Linked  Usl  With  Traverse  That  Cannot  be  Subdivided 


Identify  What  Is  Really  Needed 

Shortly  alter  wo  formally  adoptod  the  Ada 
language  (or  application  development,  we  were 
confronted  with  tho  need  to  continue  using  a  large 
library  ol  approximately  800  FORTRAN  subroutines. 
The  prospect  ot  building  an  (nterfaco  to  800  routines 
was  daunting.  Alter  some  research,  however,  we 
discovered  that  our  applications  only  called  about 
100  ot  these  routines:  the  rust  were  low-level 
supporting  program  units.  The  prospect  ot  writing 
the  Interlaces  to  100  routines  was  considerably  less 
formidable. 

With  some  linkers,  writing  an  Interface  to  a 
non-Ada  routine  Is  ail  that  Is  necessary  to  have  ti™ 
routine  included  In  the  final  linked  Image.  Under 
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these  circumstances,  Interfacing  to  only  those 
routines  actually  called  should  bo  a  requirement,  not 
an  option. 

Organize  bv  Functionality 

A  package  specification  of  ICO  routines  Is  not  a 
manageable  architecture.  In  the  case  of  our 
FORTRAN  library,  we  broke  up  the  interface  Into 
multiple  packages,  each  Identified  by  a  specific 
function;  one  package  for  forms,  another  lor  cursor 
movement,  anoilwr  for  prompting  and  reading 
responses,  etc.  This  not  only  enhanced  our  ability  to 
manage  the  routines,  but  we  also  roducoo  the 
recompilation  necessary  when  a  routine  definition 
had  to  be  corrected  or  a  now  definition  added. 


Ada-ize  the  interfaces 

Interfaces  to  operating  system  calls  are 
frequently  necessary,  and  are  a  common  problom 
area.  In  order  to  bo  tanguago  independent, 
operating  system  calls  use  low-lovol  data  typing. 
I.e„  common  data  typing  for  many  programming 
languages.  A  direct  translation  of  (iiose  data  types 
weakens  the  power  ot  Ada's  strong  data  typing. 

For  example,  consider  an  operating  system  call 
that  requires  a  bit  mask,  one  byte  In  length.  Each  bit 
in  the  mask  corresponds  to  a  setting  for  a  particular 
flag.  Of  course,  this  bit  mask  could  be  Implemented 
directly  as  an  unsignod  byte  Intoger.  but  then  the 
users  of  this  routine  would  need  to  look  up  the  flag 
that  corresponds  to  each  bit  and  determine  the 
Integer  value  of  tho  flag  settings. 

By  using  an  Ada  rocord  definition,  the  same  bit 
mask  can  be  defined  as  a  record  with  each  field 
component  corresponding  to  a  bit  tlag  (Example  0). 
To  set  the  flags,  a  user  need  only  turn  them  on  or 
off  by  name.  (Rename  can  bo  used  if  the  value 
needs  to  be  handlod  as  an  Integor  value  as  well.) 

Another  common  occurrence  In  operating 
system  calls  Is  limiting  an  argument  to  certain 
values.  For  example,  the  formal  argument  Is  defined 
as  an  Integer,  tho  only  valid  values  of  which  are 
zero.  one.  two.  and  three.  A  value  ol  zero  means 
scroll  up;  one.  scroll  down:  two,  scroll  right:  and 
three,  scroll  left. 

Defining  the  argument  as  an  INTEGER  range 
0..3  would  be  a  good  start.  At  least  the  Ada  strong 
typing  and  range  rules  can  be  used  to  our 
advantage,  and  an  out  of  range  value  would  bo 
signaled  through  CONSTRAINT_ERROR.  But  who  Is 
going  to  remember  that  zero  Is  up?  An  even 
"friendlier"  type  definition  would  be  the  enumeration 
type  shown  In  Example  9. 


lypfl  OS_G(T,MASK  is 
rocord 

FLAO_NAME_FOn_BTT_0  :  BOOLEAN  :•  FALSE: 
FLAO_NAMEJOn_0(T_I  :  BOOLEAN  :•  FALSE: 
FUOlNAME'FOR.eiO  :  OCOLEAN  FALSE: 
FLAOJTAME  jORJHTJJ  :  BOOLEAN  :>  FALSE: 
FLAGjrAMEJOfTmA  :  BOOLEAN  :•  FALSE: 
FLAQlNAMEJOnBlA  :  BOOLEAN  :•  FALSE. 
FLAGJJAMEJCrfBn^  :  BOOLEAN  :■  FALSE: 
FLAGjrAMEJOn'BiO  :  BOOLEAN  FALSE: 
one  rocord: 
for  OS„GiT_MASK  uso 
record” 

FLAG_NAME_FOR_BITO  »l  0  rsngo  0  ..  0; 
FLAG~NAME~FOR~BtT~t  ot  0  r.  no*  «  ..  1J 
FLAGlNAMEJOff bit" 2  tl  0  rshQ*  2  ..  2; 
FLAG_HAME_FCR_Brr~3  a:  0  ranoo  3  ..  3; 
FLAG_NAME_FOn_BIT~4  ai  0  ranoo  4  ..  4; 
FLAG^NAMEjorTeiO  M  0  ranoo  5  ..  5: 
FLAG  jiAMEJOff  B1T~6  at  0  ranoo  6  ..  6: 

F l AG~N AME~F OH~Orr~7  «l  0  ranoo  7  ..  7: 
and  rocord : 

lor  OS_0iTJ.iASK-&;o  uso  8: 


Example  8 

Example  ol  Using  Ada’s  Strong  Typing 
Wnari  Mining  mutiaces  to  Non-Ada  Coda 


typo  SCROLL  DIRECTIONS  Is  (UP.  DOWN.  RIGHT.  LEFT): 
tor  SCROLL  DIRECTIONS  uso  (UP  «>  0.  DOWN  .>  I. 

RjGHT  «>  2.  LEFT  ■>  3): 
lor  SCROLLDIRECTIONS'Sixa  uso  INTEGER'Suo: 

Exampl a  9 

Example  ol  Using  Ada  to  Spaolly  $  Mora  Ftlandiy. 
Ada  Consistent  Interlace 


The  Inherent  power  of  Ada  to  capture  and 
express  the  meaning  of  bit  settings  and  Integor 
values  Is  dramatically  Illustrated  In  these  two 
previous  examples.  Wo  can  note  that  these  are 
capabilities  of  the  language,  but  we  have  to  elect  to 
make  use  of  them.  It  takas  a  certain  amount  of  time 
and  effort  to  write  this  code,  but  the  returns  in  tho 
form  of  readability  and  maintainability  are  manifest. 


Recompilation  Requirements 

This  section  offers  some  random  suggestions 
for  minimizing  the  need  to  recompile  and  to 
maximize  maintainability.  It  Is  an  attempt  to  Identify 
some  key  principles  with  the  hope  that  these  will 
spur  new  ideas  and  discoveries. 
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Use  Package  Naming  Conventions 

Naming  conventions  eliminate)  confusion.  For 
example,  give  the  source  codo  filename  the  same 
name  as  the  program  unit  ft  contains.  This  facilitates 
locating  sourco  codo  files.  To  differentiate  package 
specifications  and  bodies,  uso  a  trailing  underscore 
on  tho  specification  name. 

Profix  a  program  unit’s  namo  with  tho  system  or 
subsystem  name  or  acronym.  For  example,  our  Ada 
interfaces  to  tho  run-time  library  sro  all  prefaced 
with  RTL.  This  makos  kJontifylng  the  run-time  library 
calls  and  tho  location  of  tho  sourco  codo  oasy, 
becauso  at!  RTL  packagos  aro  stored  in  ono 
location. 

Use  Srp-all.Eflctaaos 

Keep  tho  size  of  Ada  packagos  "manageable." 
In  our  experience,  this  translates  Into  having  more 
smaller  packages  rather  than  lower  oversized 
packagos.  especially  considering  tho  problems  with 
reusability  and  current  linking  technology  we 
discussed  earlier.  Qbsetvo  tho  'sevon 
pius-or-minus  two"  rule  of  thumb  to  facilitate 
comprehensibility.  Limit  tho  number  of  supporting 
program  units  in  a  packago  body  to  loss  than  fifteen 
for  the  same  roason.  In  general,  more  smaller 
packages  is  more  manageablo  than  lower  oversized 
packages. 

Also,  try  to  limit  tho  accoptablo  nestedness 
within  a  particular  program  unit  to  four  loveis. 
Anything  more  than  lour  levels  of  nestodness  makes 
it  difficult  to  understand  the  program  unit  logic:  the 
human  brain  can  handle  lust  so  much  abstraction. 

Mflnm.yisibiiitv.Qf-Pai.a- 

Although  Ada  strongly  supports  the  design 
principle  of  encapsulation,  it  Is  not  unusual  to  find 
this  principle  compromised  In  Ada  programs.  One 
situation  In  which  this  commonly  occurs  Is  data 
base  access  routines.  All  too  frequently  the  access 
Information  is  passed  from  modulo  to  modulo  along 
with  the  data,  even  though  most  of  the  modules  only 
neod  to  see  the  data:  and  a  much  smaller  number 
do  the  actual  reading  and  writing. 

Separate  tho  data  structures  from  the 
supporting  data  objocts  and  program  units.  This  will 
enable  you  to  limit  a  referenced  unit’s  visibility  to 
only  that  Information  that  Is  absolutely  necessary. 
This  provides  assurance  that  only  those  units  that 
have  the  responsibility  are  actually  modifying  the 
data  base.  In  a  few  cases,  this  technique  can 
reduce  recompilation;  but  It  is  usually  the  data 
structure  that  gets  changed,  which  means 
everything  becomes  obsolete.  If  another  database 
access  routine  Is  added  or  an  existing  one  modified, 
recompilation  Is  limited  only  to  those  routines  that 
actually  access  the  database. 


Place  type  definitions  In  their  own  packago 
specification  when  they  support  multiple  packages. 
Each  package  can  thon  reference  tho  data  typo 
definition,  subtyping  it  for  visibility  if  necessary.  This 
advico  contains  a  caveat,  however.  Bo  alort  for 
ambiguity  resulting  from  the  subtypo  names  when 
multipio  packages,  depending  on  the  same 
common  data  typo,  aro  referenced. 

Summary 

It  you  aro  building  largo  systems  with  Ada.  you 
aro  undoubtedly  confronted  with  Issues  of  imago 
sizo,  performance,  and  maintainability.  Some  of 
theso  Issues  dorfve  from  the  way  compilers  and 
tinkers  deal  with  gonorfes,  packagos.  "foreign" 
codo.  and  rocompilatlon  requirements.  This  often 
forcos  us  to  bo  concerned  about  things  that  are 
typically  outside  the  scopo  of  system  design. 

Compilers  and  linkers  will  improve,  and 
designors  will  not  bo  confronted  with  these  Issues 
within  a  reasonably  near  future.  In  the  meantime, 
theso  guidelines  will  enable  you  to  avoid  or  contend 
with  somo  ol  tho  major  architectural  concerns. 


Acknowledgments 

The  author  wtshos  to  express  her  appreciation 
to  Mr.  Drew  Yskamp  for  his  Invaluable  advice  and 
assistance. 


t  Firosmith,  Donald  "Two  Impediments  to  the 
Proper  Use  of  Ada."  Ada  Lettors 
Septomber/October,  1987 

2  Booch.  G.,  Software  Engineering  with  Ada, 
Benjamin  Cummings  Publishing  Company.  1983 


7th  Annual  National  Conference  on  Ada  Technology  1989  555 


Carolina  D.  Bachman 
Manager,  Mechanical  and  Software  CAE 
Allied -Signal  Aorospaco  Company 
Computer-Aided  Engineering  Center.  MC  3.12 
Routo  *16 

Tclcrboro.  Now  Jersoy  07603 

Mrs.  Buchman  receded  her  Bachelor  ol  Arls  in 
Physics  and  Mathematics  from  Smith  Cotlogo  in 
1978  and  hor  Master  of  Scienco  In  Computer 
Sclcnco  from  Falrloigh  Dickinson  University  In  1989. 
Sho  has  been  Involved  with  Ada  slnco  1983  whon 
Allied-Signal  Aorospaco  Company  undortook  an 
elfort  to  develop  Internal  CASE  tools  specifically 
targeted  to  Ada. 


556  7th  Annual  National  Conference  on  Ada  Technology  1989 


ADA  DESIGN  TOOL 


K.  Tuppcr,  tf  *  iviu,  J.  llcttron 
S.  Bariev,  I*.  Davanxo 

Software  Technology  Department 
Shipboard  and  Ground  Systems  Group 
Unisys  Corporation 
Great  Neele,  NY  11020 
(516)574.233? 

ABSTRACT 


This  paper  describes  the  components  of  the  Ada  Design  Tool 
(ADT),  which  is  being  developed  and  integrated  into  a 
software  engineering  environment.  This  environment  provides 
automation  and  methodology  support  foe  life-cycle  activities 
from  requirement  specification  through  unit  testing.  The  ADT 
consists  of  a  graphical  and  textual  editor  which  enables  the 
software  engineer  to  express  an  Ada  design  in  Object  Oriented 
Design  or  Functional  Decomposition.  In  addition  to  the 
editors,  the  ADT  has  a  validation  function  which  ensures  that 
the.  design  is  complete  and  consistent,  a  source  code  generator 
which  generates  the  program  templates  as  well  as  the  detailed 
code,  and  a  documentation  function  which  produces  MID-STD 
specifications  as  well  as  analytical  reports.  The  ADT  will  have 
the  capability  for  specifying  and  retrieving  reusable  design 
templates,  as  well  as  prototyping  the  design. 


1.0  Introduction 

The  software  design  tools,  available  to  us,  supported  die 
traditional  development  of  software  which  abstracts  die 
top-level  design,  through  the  use  of  a  processor  model  and 
software  architecture  descriptions,  and  the  detailed  design  via 
coding  architecture  details  and  i’DL  These  design  techniques, 
by  and  large,  are  performed  in  a  language-independent  manner, 
thereby  requiring  die  programmer  to  translate  the  stated  design 
into  the  implementation  language.  Since  Ada  is  more  than  just 
a  coding  language,  it  is  desirable  to  express  our  designs  in  Ada 
terminology,  both  at  the  top  level  as  well  as  the  detailed  level, 
thereby  eliminating  the  need  for  translation  into  a  target 
language.  Another  consideration  was  that  most  of  the  design 
tools  supported  a  single  design  method,  thereby  restricting  die 
designer  to  the  use  of  a  particular  medtodology  and  mind-set. 
Furthermore,  die  A.DT  allows  the  program  designer  to 
represent  specific  features  of  Ada  such  as  abstraction, 
multi-tasking,  exception  handling,  encapsulation,  and  generics. 


2.0  Characteristics  c-f  t‘:fc  Asa  Design  Tool 

Tlic  ADT  supports  the  Software  Engineer  in  the 
conceptualisation,  preparation,  and  generation  of  Ada 
programs.  The  ADT  i*  hosted  on  a  SUN  Workstation 
networking  system  which  gives  the  user  three  MIPS  of 
processing  power  within  a  multiple-user  environment.  The 
workstation  uses  a  multi- window  system  on  a  19-inch, 
bit-mapped  graphical  monitor,  is  menu-driven,  and  uses  a 
keyboard  and  mouse  interface.  As  part  of  a  local  life-cycle  tool 
set,  the  ADT  diagrams  and  narratives  are  stored  in  die  project 
database  to  which  access  is  controlled  through  a  relational 
database  management  system.  This  is  an  ideal  environment  for 
high  user  productivity,  programming  in  the  larjec  and  small, 
and  access  to  a  centralised  repository  of  Ada  designs. 

The  ADT  includes  a  set  of  sophisticated  editors  that  simplify 
the  creation  and  maintenance  of  several  types  cf  design 
diagrams  and  textual  descriptions.  A  user  may  access  several 
diagrams  and/or  narratives  simultaneously  through  the  use  of 
multiple  windows.  The  editors  have  been  designed  such  dial 
the  associations  between  graphical  components  and  textual 
counterparts  arc  automatically  established.  The  File 
Management  facilities  provide  for  creating,  copying,  renaming, 
deleting,  and  editing  of  the  database  entities.  To  promote 
reusability,  an  import  facility  is  provided,  allowing  access  to 
elements  in  other  projects. 

ADT  includes  a  validation  function  that  ensures  all  diagrams 
are  syntactically  correct  and  all  graphical  and  textual 
descriptions  arc  complete  and  consistent  with  one  another.  The 
ADT  will  include  a  facility  for  generating  Ada  source  code. 
The  source  code  will  be  derived  by  evaluating  the  graphical 
views  in  conjunction  with  their  textual  counterparts.  The 
documentation  function  within  the  ADT  will  produce  Software 
Design  Documents  (SDDs),  in  compliance  with 
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DOO-im>2!67A,  in  addition  to  several  analytical  report* 
summarizing  design  dcuils. 

3.0  Ada  Design  Specification  Within  APT 

Once  the  need  for  a  dedicated  Ada  design  facility  was 
recognized,  an  investigation  of  several  Ada  design  methods 
was  made.  The  techniques  examined  include  pictorial  and 
narrative  descriptions.  While  graphical  diagrams  arc  beneficial 
in  defining  program  structures  and  environmental  elements, 
textual  descriptions  serve  to  complete  lower-level  details  and 
annotations  necessary  for  a  complete  view.  It  was  concluded 
that  the  most  effective  means  of  illustrating  an  Ada  design  was 
through  a  combination  of  graphical  and  textual  details. 
Specifically,  complete  Ada  designs  can  be  represented  by  the 
series  of  ADT  diagrams  (depicted  in  succeeding  pages),  textual 
descriptions,  and  Ada-compilable  POL 

3.1  Graphical  Ada  Pcsir.n  within  ADT.  Graphical  Ada  design 
within  ADT  allows  the  user  to  represent  an  Ada  design  through 
a  series  of  diagrams  composed  of  Ada-specific  icons.  In  an 
effort  to  define  a  graphical  design  language  to  best  represent 
the  design  of  an  Ada  system  and  allow  for  leveled  design 
reviews,  an  in-depth  study  of  existing  graphical  techniques  was 
undertaken.  As  a  result  of  this  study,  it  was  decided  that  the 
ADT  would  provide  four  cooperating  graphical  views  to 
represent  an  Ada  design.  Each  view  would  contain  icons  that 
are  commonly  used  and  found  in  many  commercially  available- 
design  tools. 

There  are  three  basic  classes  of  icons:  Unit  icons,  Associative 
icons,  and  Miscellaneous  icons.Thc  Unit  icons  are  used  to 
represent  the  Ada  program  units  and  specific  types  of 
programming  constructs.  Unit  icons  are  connected  by 
Associative  icons  which  represent  the  relationship  (c.g., 
invocation,  signal,  xcess,  etc.)  between  the  units.  Each  icon 
class  has  additional  annotations  to  further  detail  the  element  or 
action  being  represented.  The  following  lists  all  icons  available 
within  the  ADT  for  the  Ada-design  diagrams. 
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The  annotations  to  unit  icons  arc  as  follows: 
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Connections  between  Unit  icons  are  made  by  Associative 
icons.  Asiocutivc  icons  m3y  represent  subprogram  calls,  entry 
calls,  cor.te.at  clauses,  execution  sequence,  etc.  as  Ievlevs ,: 
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Annotations  to  An.  -eiativc  icons  provide  further  details  on  the  The  following;  kens  ate  classified  as  Miscellaneous  icons  as 

interaction  between  Unit  icons,  and  help  define  execution  they  do  not  translate  dirtily  into  Ada  program  units  or  code, 

threads  within  the  system. 
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The  icon  set  described  above  will  be  used  to  generate  four 
specific  conceptual  views  of  a  system:  environmental, 
communication,  struct'  jl,  and  physical. 

The  environmental  view  consists  of  a  Context  Diagram  which 
describes  the  boundary  between  '.he  software  system  under 
development  and  its  environment,  including  externally 
imported  code. 

Figure  1  is  an  example  of  an  ADT  Context  Diagram. 

The  communication  view  is  used  to  illustrate  the 
communication  and  interaction  between  the  major  Ada  units 
within  the  system  being  modeled.  The  ACa  Communication 
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Diagram  (ACD)  will  recent  all  program  units  which 
communicate  through  rendezvous,  at  well  at  the  specific 
details  of  the  rendezvous;  calls  to  procedures  within  packages, 
including  the  specific  details  of  the  calls;  and  calls  to  major 
subprogram  units,  as  well  at  the  details  of  the  calls. 


The  ACD,  accompanied  by  the  textual  descriptions  and 
Context  Diagram,  serves  as  an  excellent  tool  for  a  top-level 
view  of  the  system. 

Figure  2  illustrates  an  example  of  an  ACD. 
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The  intern*!  logic,  sequence,  and  structure  within  a  program 
unit  is  represented  by  an  Ada  Structure  Diagram  (ASD).  The 
ASD  is  simular  to  a  Structure  Chart,  but  has  been  extended  to 
encompass  Ada  specific  constructs  and  details.  Accept 
statements,  block  structures,  exception  handlers,  loops,  cases, 
and  if  statements  are  all  illustrated  on  an  ASD.  ASD*  may  be 
leveled  to  avoid  over  crowding.  The  users  of  the  tool 
determine  the  level  of  detail  shown  on  an  ASD.  The  tool  will 
generate  source  code  for  an  Ada  Unit  based  on  level  of  detail 
entered. 

figure  3  is  an  example  of  an  ASD. 


The  physical  view  of  the  system  is  used  to  illustrate  the 
compilation  units  and  subunits  and  their  file  organization 
within  the  system  through  context  clauses,  sequence  markers, 
and  other  annotations  on  a  Physical  Layout  Diagram  (PLD). 
PLDs  enable  the  user  to  define  and  represent  the  file  structure 
for  storing  the  program  elements  within  the  application.  This 
information  is  used  by  the  source  code  generation  function  to 
determine  the  "withing"  of  the  various  program  entities  and  by 
the  Configuration  Management  Function  for  tracking  the 
creation,  modification,  and  access  of  compilation  unit  files. 
This  diagram  also  aids  the  Software  Engineer  in  partitioning 
the  system  to  minimize  recompilation. 

Figure  4  illustrates  an  example  of  a  PLD. 
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Figure  4.  Bank  ‘^ra«l»tk«  Sytitm  ■  Physical  tjyoul  Diifram 


3.2  Textual  Detail*  of  an  Ada  Design.  A  textual-details 
window  is  provided  for  each  subprogram,  package,  task,  and 
block  unit  icon  within  the  system.  Prompts  arc  provided  within 
the  window  to  define  information  that  is  relevant  to  the 
corresponding  Ada  unit.  Each  unit's  details  window  contains 
an  explosion  field  to  define  the  next  lower  level  definition,  a 
compilation  unit  field  to  specify  the  name  of  the  file  in  which 
the  unit  is  contained,  a  description  field,  a  declarative  section 
definition,  and,  if  appropriate,  a  file  for  separately  defined 
bodies.  The  user  will  be  responsible  for  entering  all 
information  required  to  generate  declarations  and  perform 
consistency  checks  between  data  definitions  and  usage. 
Information  (such  as  identification  and  purpose,  relationship  to 
other  units,  and  other  definitive  information)  not  contained  in 
the  ADT  diagram  that  is  used  to  satisfy  the  detailed  design 
requirements  should  be  specified  in  the  description  field.  Each 
details  window  also  includes  fields  dedicated  to  the  unit  or 
structure  being  defined  (e.g.,  entry  points,  parameters,  etc.). 
Examples  of  each  program  unit  or  structure  textual  details  may 
be  found  in  the  right-hand  column. 


4.0  Validation 

The  ADT  validation  function  consists  of  two  main 
components:  syntax  checking  and 
completencss-and-consistency  analysis.  The  validation  checks 
can  be  performed  on  the  entire  Ada  design  or  any 
user-specified  subset 

Syntax  checks  are  performed  on  each  type  of  diagram  to  ensure 


SUBPROGRAM  DETAILS 

Name: 

Name  of  subprogram 

Subprogram  Type: 

Procedure,  Function 

Main  Procedure 

Priority: 

Applicable  to  main  procedure  only 

Expiation  Type: 

ACD.ASD.PDL.clc. 

Source  Code  File: 

File  in  which  Ada  source  is 
contained 

Parent  Unit: 

Name  of  unit  in  which  subprogram 
it  contained  (if  applicable) 

Parent  Unit  Type: 

Type  of  parent  unit 
(if  applicable) 

Formal  Parameters: 

Declarative  Section: 

List  of  all  objects  and  types 
defined  within  the  declarative  section 
of  the  subprogram  body 

Exceptions: 

List  of  all  exceptions  handled 
and/or  propagated  within  the 
subprogram 

Description: 
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that  basic  software  engineering  principles  as  well  as  Ada 
specific  concepts  are  not  violated. 

The  following  are  some  of  the  major  syntax  checks: 


•  Evcty  object  is  labeled  and  numbered  correctly 

•  Free  standing  objects  are  not  allowed 

•  There  are  no  off-page  Associative  Icons 

•  Actual-parameters  match  formal  parameters 
definitions 

•  Every  External  Entity  is  connected  to  the  system 
directly,  via  a  Context  Clause,  or  indirectly,  using  a 
Library  Package,  via  a  Dau  Dus. 

The  completcness-and-consistency  analysis  ensures  that  all 
objects  within  the  scope  of  this  validation  analysis  are  fully 
defined  by  their  corresponding  textual  details  and  their  usage  is 
consistent  with  other  objects  in  the  design  database. 

5.0  APT  Source  Code  Generation 

The  APT  Source  Code  Generation  facility  will  generate 
program  templates  in  addition  to  detailed  code.  By  analyzing 
A  CDs  and  xcompanying  textual  details,  program  templates 
(which  include  task  specifications,  package  specifications,  and 
rendezvous  constructs)  can  be  generated.  ASDs  and  associated 
textual  detail  interpretation  supply  lower-level  logic  and 
sequence  details  to  complete  the  Ada  program.  The  use  of  the 
APT  Source  Code  Generator  will  eliminate  syntax  errors,  and 
enforce  the  use  of  desired  programming  standards. 

Furthermore,  changes  in  program  design  immediately  can  be 
reflected  in  the  code. 

6.0  Automatic  Report  and  Document  Generation 

The  APT  will  provide  a  turn-key  documentation  facility  from 
the  design  database.  Analytical  reports  (such  as  Where  Used 
and  Data  Dictionary  reports)  are  generated  to  aid  the  software 
engineer  in  the  creation  of  the  Ada  design.  The  hardcopy 
documents  produced  are  formal  Software  Design  Documents  in 
compliance  with  DOD-STD-2167A.  The  document  generator 
automatically  provides  section  heading  generation,  page 
numbering,  figure  numbering,  table  of  contents  generation, 
security  markings,  figure  cross-reference  generation,  and 
merging  of  text  and  figures  on  the  same  page.  Tne  final  design 
documentation  will  be  produced  on  a  commercially  available 
publishing  system.  The  document  generator  turns  out  an 
intermediate  design  document  containing  publication 
commands  for  the  publication  system.  A  Customizer  Kit  will 


TASK  DETAILS 

Name: 

Name  of  tad: 

Task  Type: 

Anonymous  or  Task  Type 

Number  of  occurrences: 

Expiation  Type: 

ACD,  ASD,  PPL,  etc. 

Priority: 

Representation  Clause: 

Source  Code  FUe: 

Name  of  file  in  which  Ada  source 
it  contained 

Master  Program  Unit: 

Name  of  unit  in  which  task 
is  defined 

Declarative  Section: 

List  of  all  objects  and  types 
defined  within  the  declarative  section 
of  the  task  body 

Entry  Points 

1)  Entry  Name 

Parameters: 

2)  Entry  Nsme 

Parameters: 

n)  Entry  Name 

Parameters 

Exceptions: 

List  of  all  exceptions  processed 
and/or  propagated  within  the  task 

Description: 
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allow  die  uk?  to  tailor  the  format  of  the  report!  and  documents 
K>  specific  needs,  miking  it  flexible  to  other  documentation 
standards. 


SUMMARY 

ADT  is  in  Adi  Design  Tool  which  enables  the  Software 
Engineer  to  represent  a  top-level  and  detailed-level  design  in 
terms  of  the  Adi  language  through  the  use  of  sophisticated 
graphical  and  textual  editors.  The  tool  can  be  used  effectively 
to  automate  both  the  Object  Oriented  and  functional 
Decomposition  Design  approaches,  fn  addition,  ADT  takes 
advantage  of  the  richness  of  the  Ada  language,  and  supports  the 
principles  and  goals  of  good  software  engineering  practices. 

The  ADT  is  scheduled  for  Alpha  test  in  April  1919  and  Beta 
release  in  June  1989.  Subsequent  releases  will  contain  the  Ada 
Source  Code  Generator  for  the  program  structure  as  welt  as  the 
detailed  code. 


BLOCK  DETAILS 

Name: 

Name  of  Block 

Block  Type: 

Standard,  Accept,  POL,  Exception 

Explosion  Type: 

ACD,  ASD,  POL,  etc. 

Parent  Unit: 

Name  of  unit  in  which  block  is 
contained 

Parent  Unit  Type: 

Type  of  unit  in  which  parent 
is  contained 

I 

s 

1 

1 

Name  of  file  in  which  parent 

Ada  source  is  contained 

Declarative  Section: 

List  of  all  data  elements  defined 
within  the  declarative  section 
of  the  block 

Exctpikmc 

List  of  all  exceptions  processed 
and/or  propagated  within  the  block 

Description: 
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PACKAGE  DETAILS 

NAME: 

Name  of  Package 

Exptafcm  Type: 

ACD,  ASD,  POL,  etc. 

Source  Coda  File: 

Name  of  file  in  which  Ada  source 
is  contained 

Parent  Unit: 

Name  of  unit  In  which  package 
it  contained  (if  applicable) 

Parent  Unit  Type: 

Type  of  Parent  Unit 
(if  applicable) 

Specification: 

List  of  all  objects  and  types 
defined  in  the  specification  of  the 
package 

Declarative  Section: 

List  of  all  objects  and  types 
defined  within  the  declarative  section 
of  the  package  body 

Exceptions: 

List  of  exception  processed  and/or 
propagated  in  the  package  body 

Description: 
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OBJECTS  WITH  MULTIPLE  REPRESENTATIONS  IN  ADA 


K.  M.  George 


Jag  Sodhi 


Oklahoma  State  University 
Stillwater,  Oklahoma 

ABSTRACT!! 

Ada  provides  the  facility  for  the  separation  of  specification  and 
implementation.  However,  there  is  a  one-to-one 
eottespondcnce  between  a  specification  and  its  implementation 
(if  one  exists).  This  paper  presents  an  implementation  scheme 
which  provides  multiple  representations  of  an  object.  It  is 
possible  to  choose  an  implementation  from  the  available 
implementations.  The  user  of  the  specification  need  not  be 
concerned  with  the  details  of  implementation. 

1.0  INTRODUCTION 

A  programming  paradigm  such  as  object  oriented 
programming  which  permits  separation  of  specification  and 
implementation  provides  several  advantages.  Specification 
provides  an  abstraction  from  computation  [LIGU  86)  which 
allows  the  use  of  complex  objects  without  having  to  be 
concerned  with  their  implementation.  The  user  of  a 
specification  is  spared  from  the  implementation  details.  The 
burden  of  the  appropriate  choice  of  data  structures  is  handled 
in  the  implementation  and  can  be  postponed  as  long  as 
necessary.  However,  once  the  implementation  chooses  a  data 
structure  the  user  has  no  other  choice.  Modem  programming 
languages  incorporate  this  concept  in  their  design  and  provide 
adequate  facilities  for  separation  of  specification  and 
implementation.  In  particular,  Ada  (VAXA)  supports  this 
separation  of  specification  and  implementation  in  generics, 
packages,  tasks  etc.  The  implementation  bundles  together  data 
structures  and  the  operations  on  the  data  structures.  The 
specification  provides  the  view  of  an  object  and  a  set  of 
operations  on  it.  Put  another  way,  the  specification  provides 
the  view  of  an  abstract  data  type  (CAWE  85).  There  is  a  one- 
to-one  correspondence  between  the  specification  and 
implementation.  The  user  of  the  specification  has  no  control 
over  the  choice  of  data  structures  and  algorithms  used  in  the 
implementation. 
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of  the  problem  and  an  Ada  solution.  The  complete  Ada 

Sram  and  output  from  a  trial  run  arc  given  in  the  appendix. 

c  side  effects  of  the  solution  are  discussed  in  section  3; 
and  section  4  is  the  conclusion. 

IQ  ABSTRACT  DATA  TYPE 

An  abstract  data  type  (ADT)  consists  of  a  set  of  objects  and  a 
set  of  operations  characterizing  the  behavior  of  the  objects 
|UGU  86).  The  set  of  objects  can  be  defined  using  relations 
of  the  operations.  The  specification  of  the  ADT  provides  the 
name  of  the  ADT  and  the  names  of  the.  operations.  The  details 
of  the  operations  arc  hidden  in  the  implementation.  An 
implementation  of  an  ADT  is  called  a  realization  of  the  ADT. 
An  ADT  can  have  more  than  one  realization.  An  example  is 
given  in  the  next  section. 

2 A  EXAMPLE 

Let  us  examine  the  ADT  "stack"  and  two  of  its  possible 
implementations.  The  ADT  stack  is  defined  by  a  set  of 
functions  and  a  set  of  defining  relations.  The  implementations 
using  an  array  and  a  linked  list  are  examined. 

abstype  STACK  is 

functions : 

PUSH  :  STACK  X  OBJECT ->  STACK 
POP  :  STACK  -•>  STACK 
TOP  :  STACK -->  OBJECT 

relations: 

POP  (  PUSH  )  ■  id 
PUSH  (  POP,  TOP)  «  id  if  STACK  is  not 
EMPTY 

end  STACK 


In  some  applications,  efficiency  might  depend  on  die  choice  of 
data  structures  and  algorithms.  In  such  cases,  the  facility  to 
select  an  implementation  will  be  useful.  As  an  example, 
consider  a  linear  programming  problem.  The  type  of  efficient 
representations  are  different  for  large  sparse  matrices  and  small 
matrices.  The  particular  choice  will  depend  on  the  application. 
So,  ideally,  one  would  like  to  have  a  linear  programming 
package  with  the  flexibility  to  choose  efficient  representation. 
The  issue,  then,  is  to  provide  specifications  of  abstract  data 
types  together  with  the  capability  to  choose  appropriate 
implementation.  Such  specification  should  not  diminish  the 
advantages  of  the  separation  of  specification  and 
implementau'on.  This  paper  is  concerned  with  an  Ada  solution 
to  multiple  rcprcscntauons  of  abstract  data  types  and  the  means 
to  choose  an  implementation.  The  user  of  the  specification  still 
need  not  be  concerned  with  implementation  details.  The  next 
section  provides  a  definition  of  abstract  data  type,  an  example 


The  implementations  must  obey  the  defining  relationships  of 
the  ADT.  Two  implementation  schemes  arc  shown  below: 

1)  array-implementation  is 
/*  using  scalar  I  and  array  A  */ 

1  0; 

PUSH: 

I  <-- 1+1;  A[I]  <--  X;  /♦  X  is  an  object  ♦/ 

POP: 

I  <-- 1-1; 

TOP: 

value  of  All); 
end  array-implementation; 
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2)  iiwhcd-list-impicmcntarion  fa 

/*  using  HEAD  u  pointer  to  the  top  of  the  lint,  and 
a  structure  LIST  with  two  component*  INFO  and 
UNK*/ 

HEAD  <-  NULL; 

PUSH: 

TEMP  <~  new  UST  /*  TEMP  U  a  temporary 
pointer  to  a  cell  */ 

TEMP.INFO  <-•  X;  TEMPllNK  <~  HEAD; 

HEAD  <--  TEMP; 

POP: 

HEAD  <~  HEAD.UNK; 

TOP: 

value  of  HEAD.INFO; 
end  Imked-liw-inylementadon; 

In  the  above  implementation  schemes,  the  data  structures 
array,  the  linked  list,  and  both  pertinent  scalar  variables  I  and 
HEAD  are  Internal  to  the  implementation.  The  operations 
PUSH,  POP  and  TOP  are  the  only  names  visible  to  outside 
users.  It  is  easy  to  verify  that  boot  implementation  schemes 
satisfy  the  denning  equations.  It  is  also  obvious  that  the 
implementations  of  functions  are  directly  related  to  the  data 
structure  chosen  for  the  implementation.  When  an 
implementation  is  abstracted  information  is  lost.  In  order  to  be 
able  to  choose  a  specific  implementation,  relevant  information 
must  be  preserved  by  the  abstraction.  So,  in  this  paper  we 
examine  an  abstraction  process  which  preserves  the  relevant 
information. 


An  ADT  can  be  implemented  using  several  data  structures. 
We  call  an  impleiaen^tion  of  an  APT  V  a  realization  of  t.  A 
realization  essentially  la  a  data  structure.  The  definition  of  a 
data  Structure  ti  given  by  Reingold  and  Hansen  (REHA  83)  is 
shown  below. 

A  data  structure  consists  of  three  components: 

1)  t  set  of  function  definitions, 

2)  a  storage  structure,  and 

3)  a  set  of  algorithms,  one  for  each  function. 

For  our  discussion,  an  algorithm  is  identified  with  Us  function 
name.  Therefore,  we  can  view  a  data  structure  as  a  pair  (SJ5) 
where  S  represents  a  storage  structure  and  FrcprescnU  a  set  of 
functions.  An  equivalence  class  structure  can  be  imposed  on  a 
set  of  data  structures.  Let  D  be  a  set  of  data  structures.  Two 
data  structures  dj  ■  (Si,Fj)  and  d2  ■  (S2.F2)  in  D  arc 
equivalent  if  d)  and  d2  are  realizations  for  the  same  set  of 
ADTs.  If  D  consists  of  exactly  one  equivalence  class  and  if 
the  equivalence  is  imposed  by  an  ADT  t,  then  D  is  called  a 
realization  clan  for  t.  In  other  words,  every  member  of  D  will 
be  an  implementation  of  the  ADT  t.  The  set  D  contains  more 
information  (eg.  storage  structure)  than  the  ADT  I  itself.  If  the 
information  hidden  in  D  is  available  to  the  user  of  t,  then  that 
user  will  be  able  10  choose  the  appropriate  realization  based  on 
the  application  from  D.  This  can  be  achieved  by  viewing  D  as 
a  type.  We  call  this  type  realization.  Using  D  and  t,  we  can 
define  a  new  type  which  allows  one  to  select  a  realization  for 
an  ADT.  This  new  type  is  called  ribstvpc  where,  as  an  ADT, 
it  is  called  ahttype.  The  tormal  definitions  are  given  below: 

1)  TYPE  ;i  realization 

VALUES  are  in  D 

OPERATION  is  selection:  D  ->  d,  where  d  is  a 
member  of  P, 


2)  TYPE  is  rabstype 
VALUES  are  lu  xD 
OPERATION  is  binding:  (id)  ~>  t.d 

where  id  refers  to  an  instance  of  ( with  realiza¬ 
tion  d. 

An  Ada  package  specification  for  the  ADT  stack  is  given  in  the 
next  section.  The  operations,  selection  and  binding,  defined 
above  will  correspond  to  an  instantiation  of  a  generic  package. 
The  type  rabstype  is  implemented  as  a  generic  package 
specification. 


In  order  to  implement  the  above  concepts  in  Ada,  the 
realization  type  should  be  visible  through  the  specification. 
The  following  package  specification  provides  a  specification: 

package  STACKJMPLEMENTATION.UST  is 
type  UST_OfvSTACKJMP„TYPE  is 

(ARRAY JMP,  UNKEDJJSTJMP); 

generic 

STACKJMP :  L1ST_0F_SYACK_IMP_TYPE; 
package  STACK  is 

procedure  PUSH  (OBJECT  :  INTEGER); 
procedure  POP; 

function  TOP  return  INTEGER; 
end  STACK; 

end  STACK_iMPLEMENTAT10N_UST, 

The  list  of  available  implementations  are  made  visible  as  the 
values  associated  to  the  enumeration  type 
Li ST_OF„ST A CK_t M P..TYPE.  The  choice  of  an 
Implementation  is  the  same  as  instantiation  of  the  generic 
package  STACK  using  the  appropriate  value.  For  the 
complete  implementation  and  a  test  run,  the  reader  is  referred 
to  the  appendix.  Some  of  the  advantages  and  disadvantages 
related  to  this  approach  are  discussed  in  the  next  section. 


The  method  illustrated  by  the  specification  in  the  previous 
section  can  be  used  to  construct  interfaces  to  reusable 
software.  The  specification  can  be  viewed  as  a  window  as 
shown  in  figure  i. 


OBJECT  NAMES 


FUNCTION  NAMEJ 


Figure  1 


Object  names  refer  to  implementation  type  and  the  function 
names  refer  to  1  function  or  a  procedure.  For  example, 
assume  that  there  are  severe!  procedures  which  implement 
sorting  algorithms  such  as  bubble  sort,  quick  sort  etc.  Then 
the  function  name  can  be  sort  and  object  names  can  be  bubble, 
quick  etc.  The  advanMge  is  that  the  user  of  the  specification 
needs  to  be  concerns;.  only  with  the  algorithm  type  and  the 
name  of  the  function.  The  user  need  not  know  which 
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packages  to  use  or  whsupccific  name  to  use  and  so  on.  The 
disadvantage,  however,  it  the  inefficiency  associated  to 
generic  instantiation.  The  runtime  inefficiency  probably  can  be 
removed  by  appropriate.  substitutions  st  compile  time  if  such 
capability  exist*. 


4.0  CONCLUSION 

In  this  paper  we  have  addrassed  the  ittue  of  multiple 
Implementation*  and  dynamic  implementation  choice  of 
abstract  daw  type*  in  Ada.  The  method  uted  it  illustrated 
using  an  example,  a  complete  Ada  program.  The  separation  of 
specification  and  implementation  it  not  compromised,  in 
order  to  provide  a  choice  of  implementation,  a  level  of 
abstraction  is  chosen  such  that  the  names  of  implementation 
arc  risible. 
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APPENDIX 


Thi«  package  prividea  the  liat  of  available  iaplewentationa  of  the  abatcact 

—  data  type  STACK. 

package  STAC K_I MPLEMEMTAT I OM_L 1ST  la 

type  LI ST_Or_STACK_IHF_TYPE  ia  { AR KAT_I HP , LI NKED_LI ST J HP ) ; 

—  Llat  of  iaplewentationa.  ~  “ 

generic 

STACK_IMP  i  LI ST_OP  STACK  I HP  TYPE ;  —  Iapleaetation  type  to  be  choaen. 

—  Abaract  data  type  Tolloua: 
package  STACK  ia 

procedure  POSH  (OBJECT: INTEGER) ; 
procedure  POP; 
function  TOP  return  1HTEGER; 
end  STACK; 

end  STACK_I MPLEMEMTAT I OH_L I ST ; 
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This  package  body  contains  all  implementations  including  the  subprograms 
—  associated  to  abstract  data  type  STACK. 


with  TEXT  10?  use  TEXT  10; 

package  body  STACK_I HPEemENTAT I ON_LI ST  is 


package  XNT  10  is  new  INTEGER  I 0 { INTEGER) ; 
use  I NT  10;" 

type  ARlATJTYPE  is  array  (1..100)  of  INTEGER; 
type  NODE; 

type  LINK  is  access  NODE; 
type  NODE  is 
record 


VALUE  s  INTEGER; 
NEXT  :  LINK; 
end  record; 

STACK  ARRAY  {ARRAY  TYPE; 

stack"top  s  inteCer  0; 
LINK  Top  :  LINK  t-  null; 


—  storage  for  array 

—  implementation. 


—  storaae  for  linked 

—  list  implementation. 


—  stack  top  for  array 

—  stack  top  for  linked 


—  Array  implementation  of  PUSH. 

procedure  ARRAY  PUSH  (OBJECT* INTEGER)  is 
begin 

STACK  TOP  :■  STACK  TOP  ♦  1; 

STACKJkRRAY  (STACK**T0P)  I-  01JECT; 

—  Messages  to  verify  the  actions. 

Ptm-ARRAY  IMPLEMETATION  Of  PUSH  IS  USED  AND  VALUE  PUSHED  IS"); 
PUT(OBJECT) ; 

NEW  LINE; 
end  ARRXY  PUSH; 


—  Linked  list  implementation  of  PUSH. 

procedure  LINK  PUSH  (OBJECT  t  INTEGER)  is 
TEMP  ;  LINK; 
begin 

TEMP  t-  new  NODE; 

TEMP. VALUE  !•  OBJECT; 

TEMP. NEXT  f  LIN.t  TOP; 

LINKJTOP  TEMP;" 

—  Messages  to  verify  the  actions. 

PUTCLXNK  IMPLEMENTATION  Or  PUSH  IS  USED  AND  VALUE  PUSHED  IS" ) ; 
PUT (OBJECT) ; 

NEW  LINE; 
end  LINK  PUSH; 


-  Array  implementation  of  POP. 

procedure  ARRAY_P0P  is 
begin 

STACK_T0P  :•  STACK  TOP  -  1; 

-  Messages  to  verify  the  actions. 

PUT( ’ARRAY  IMPLEMENTATION  OP  STACK  IS  USED  AND  VALUE  POPED  IS*); 
PUT (STACK  ARRAYtSTACK  TOP+1)); 

NEW  LINE;" 
end  ARRKY  POP; 


list 


570  7th  Annual  National  Conference  on  Ada  Technology  1989 


Linked  list  implementation  of  POP. 
procedure  LINK  POP  is 
begin 

Messages  to  verify  the  actions. 

PUT(*LINK  IMPLEMENTATION  OP  STACK  IS  USED  AND  VALUE  POPED  IS*); 

PUTiLINK  TOP. VALUE) ; 

NEW  LINEj 

LINK  TOP  :■  LINK  TOP. NEXT; 
end  LINK'POP; 

Array  implementation  of  the  function  TOP. 
function  ARRAYJTOP  return  INTEGER  is 
begin 

Messages  to  verify  the  actions. 

PUT( "ARRAY  IMPLEMENTATION  Or  STACK  IS  USED  AND  VALUE  OF  TOP  IS*); 

PUT (STACK  ARRAY (STACK  TOP)); 

NEW  LINE;- 

return  STACK  ARRAY (STACK  TOP); 
end  ARRAY JTOP;  ~ 

Linked  list  implementation  of  the  function  TOP. 
function  LINK  LISTTOP  return  INTEGER  is 
begin 

Messages  to  verify  the  actions. 

PUT("LINK  IMPLEMENTATION  OP  STACK  IS  USED  AND  VALUE  OF  TOP  IS"); 

PUTtLINK  TOP. VALUE); 

NEW  LINE? 

return  LINK  TOP.VALUE; 
and  LI NK_LI STJTCp ; 

The  Implementation  of  the  abstract  data  type  STACK.  It  uses  one  of  the  above 
Defined  Implementations, 
package  body  STACK  is 

procedure  PUSH  (OUECT  :  INTEGER)  is 
begin 

if  STACK  IMP  ■  ARRAY  IMP  then 
ARRAY  PUSH(OBJECT); 

elsif  STACK  IMP  -  LINKED  LIST  IMP  then 
LINK  PU?H (OBJECT) ;  “ 

else 

null; 
end  if; 
end  PUSH; 

procedure  POP  is 
begin 

if  STACK  IMP  -  ARRAY  IMP  then 
ARRAY  POP; 

elsif  STACK  IMP  -  LINKED  LIST  IMP  then 
LINK  POP; 

else 

null; 
end  if; 
end  POP; 
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function  TOP  return  INTEGER  i* 
begin 

if  STACK  IMP  »  ARRAY  iMP  then 
return  ARRAY  TOP? 

elsif  STACK  IMP  -  LINKED  LIST  IMP  then 
return  ElHK_LIST_TOP“ 

else 

return  -1000; 
end  if; 
end  TOP; 
end  STACK; 

end  STACK_1MPLEMENTATI0N_LIST; 
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—  This  •  Min  program  to  test  the  package  STACK  which  is  a  generic  package 

—  which  implements  the  abstract  data  type  STACK.  It  is  possible  to  select  the 

—  implementation  one  likes  from  among  the  available  implementations.  This 

—  programs  tests  the  generic  package  STACK  by  instantiating  with  the  two 

—  possible  values. 

—  Since  its  purpose  is  to  verify  the  relevant  packages,  there  are  no  means 
--  of  handling  exceptions. 

with  TEXT  10;  use  TEXT  10; 
with  STACK  IMPLEMENT ATTOK  LIST; 

use  stack  Implementation  Eist; 

pcocedure“STACK  CHECK  is“ 

package  INT  TO  is  new  INTEGER  10 (INTEGER) ; 
use  1NT_I0; 
begin 

—  Test  array  implementation  of  STACK, 
declare 

package  STACK  PACKAGE  is  new  STACK (ARRAY  IMP); 
use  STACK  PACKAGE; 

X,Y: INTEGER; 
begin 

(or  I  in  1..5  loop 

PUTClNTEGER  TO  BE  POSHED  s'); 

GET(X) ; 

NEW  LINE; 

PUSK(X); 

T  :«  TOP; 
end  loop; 

(or  1  in  1..4  loop 
POP; 

T  :■  TOP* 

PUTCNEw'tOP  IS  ;•); 

PUT(T); 

NEW_LINE; 
end  loop; 
end; 

—  Test  linked  list  implementation  o(  STACK, 
declare 

package  STACK  PACKAGE  is  new  STACK (LINKED  LIST  IMP); 
use  STACK  PACKAGE; 

X,Y: INTEGER; 
begin 

(or  I  in  1..5  loop 

PUT ("INTEGER  TO  BE  PUSHED  :*); 

GET(X) ; 

NEW  LINE; 

PUSR(X); 

T  :«  TOP; 
end  loop; 

(or  1  in  1..4  loop 
POP; 

T  TOP; 

PUTCNEW  TOP  IS  :"); 

POT(Y); 

NEW_LINE; 
end  loop; 

end; 
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SAMPLE  OUTPUT 


INTEGER  TO  BE  PUSHED  : 

ARRAY  IMPLEHETATION  OP  PUSH  IS  USED  AND  VALUE  PUSHED  IS  100 

ARRAY  IMPLEMENTATION  OP  STACK  IS  USED  AND  VALUE  OF  TOP  IS  100 

INTEGER  TO  BE  PUSHED  : 

ARRAY  I MPLEMETATI ON  OP  PUSH  IS  USED  AND  VALUE  PUSHED  IS  200 

ARRAY  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  OP  TOP  IS  200 

INTEGER  TO  BE  PUSHED  : 

ARRAY  I MPLEMETATION  OP  PUSH  IS  USED  AND  VALUE  PUSHED  IS  300 

ARRAY  IMPLEMENTATION  OP  STACK  IS  USED  AND  VALUE  OP  TOP  IS  300 

INTEGER  TO  BE  PUSHED  : 

ARRAY  I MPLEMETAT I ON  OP  PUSH  IS  USED  AND  VALUE  PUSHED  IS  400 

ARRAY  IMPLEMENTATION  OP  STACK  IS  USED  AND  VALUE  OF  TOP  IS  400 

INTEGER  TO  BE  PUSHED  : 

ARRAY  I  MPLEMETATI  ON  OP  PUSH  IS  USED  AND  VALUE  PUSHED  IS  500 

ARRAY  IMPLEMENTATION  OP  STACK  IS  USED  AND  VALUE  OP  TOP  IS  500 

ARRAY  IMPLEMENTATION  Or  STACK  IS  USED  AND  VALUE  POPED  IS  500 

ARRAY  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  OP  TOP  IS  400 

NEW  TOP  IS  :  400 

ARRAY  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  POPED  IS  400 

ARRAY  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  Or  TOP  IS  300 

NEW  TOP  IS  :  300 

ARRAY  IMPLEMENTATION  OP  STACK  IS  USED  AND  VALUE  POPED  IS  300 

ARRAY  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  OP  TOP  IS  200 

NEW  TOP  IS  :  200 

ARRAY  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  POPED  IS  200 

ARRAY  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  OP  TOP  IS  100 

NEW  TOP  IS  l  100 

INTEGER  TO  BE  PUSHED  : 

LINK  IMPLEMENTATION  OF  PUSH  IS  USED  AND  VALUE  PUSHED  IS  600 

LINK  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  OF  TOP  IS  600 

INTEGER  TO  BE  PUSHED  : 

LINK  IMPLEMENTATION  OP  PUSH  IS  USED  AND  VALUE  PUSHED  IS  700 

LINK  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  OF  TOP  IS  700 

INTEGER  TO  BE  PUSHED  : 

LI Nr  IMPLEMENTATION  OF  PUSH  IS  USED  AND  VALUE  PUSHED  IS  800 

LINK  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  Or  TOP  IS  800 

INTEGER  TO  BE  PUSHED  : 

LINK  IMPLEMENTATION  OF  PUSH  IS  USED  AND  VALUE  PUSHED  IS  900 

LINK  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  Or  TOP  IS  900 

INTEGER  TO  BE  PUSHED  : 

LINK  IMPLEMENTATION  OF  PUSH  IS  USED  AND  VALUE  PUSHED  IS  1000 

LINK  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  OF  TOP  IS  1000 

LINK  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  POPED  IS  1000 

LINK  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  OF  TOP  IS  900 

NEW  TOP  IS  J  900 

LINK  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  POPED  IS  900 

LINK  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  OF  TOP  IS  800 

NEW  TOP  IS  s  800 

LINK  IMPLEMENTATION  OP  STACK  IS  USED  AND  VALUE  POPED  IS  800 

LINK  IMPLEMENTATION  OP  STACK  IS  USED  AND  VALUE  OP  TOP  IS  700 

NEW  TOP  IS  :  700 

LINK  IMPLEMENTATION  OF  STACK  IS  USED  AND  VALUE  POPED  IS  700 

LINK  IMPLEMENTATION  OP  STACK  IS  USED  AND  VALUE  OF  TOP  IS  600 

NEW  TOP  IS  :  600 
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A  Software  Development  Tool  Using  Ada  — 
Pseudo  cade  Management  System 
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ABSTRACT 

This  software  development  tool  will 
allow  for  completion  of  one  of  the 
detailed  design  specifications, 
contributing  to  the  architectural  design 
and  the  detailed  design  modular izncion 
of  the  software  product.  The  interface 
specifications  for  Che  various  modules 
are  incorporated  within  a  "Modulo_ 
Template".  This  Moduie_Tcmplate  and  thu 
pseudocode  body  can  lator  be  expanded 
into  source  code.  The  PCMS  will  allow 
systom  designers  to  document  and  track 
software  modules  more  effectively  ns 
they  ore  being  created.  It  also  has  the 
capability  to  recontrucc  a  structured 
chart  graphically  for  a  given  subsystem. 


I.  INTRODUCTION 


During  the  development  of  a  software 
product,  it  Is  helpful  to  provldo 
various  tools  and  mechanisms  wheroby 
tho  programmers  working  on  the  product 
can  document  tho  development  cycles 
and  Identify  tho  various  inter¬ 
connecting  paths  between  modules. 

This  facilitates  tho  easy  generation 
and  maintenance  of  robust,  efficient 
codes. 

Our  goal  Is  to  design  such  a  soft¬ 
ware  development  tool  to  aid  in  tho 
design  of  a  software  product.  This 
tool  will  allow  for  completion  of  one 
of  the  detailed  design  specifications, 
contributing  to  the  architectural 
design  and  the  detailed  design  modu¬ 
larization  of  tho  software  product. 

One  of  the  area  that  such  a  tool  is 
advantageous  is  during  tho  initial 
design  of  the  interface  specifications 
for  tho  various  modules  written  for 
the  subsystem  of  the  product.  These 
specifications  are  often  incorporated 


within  a  Moduli*  Template".  An  example  or 
such  a  template  Ts  shown  in  section  II. 
This  template  ultimately  leads  to  the 
creation  of  the  pseudo-code  body. 

This  module  template  and  the  pseudo¬ 
code  body  can  later  be  expanded  into 
sourco  code.  Modules  Interface  specifica¬ 
tions  such  as  the  Module_Temploto  are 
effective  notations  for  architectural 
design  when  they  are  used  in  combinning 
with  structured  charts  and  data  flow 
diagrams.  They  also  provide  a  natural 
transition  from  architectural  design  to 
detail  design,  and  from  dotal i  design  to 
Implementation. 


The  development  of  any  software  pro¬ 
duct  Is  an  expansive  and  tlme-eomsumlng 
process.  Tho  need  for  accurato,  well- 
documontod,  maintcnoble  source  code  is 
evidenced  by  the  growing  amount  of 
emphasis  placed  on  fault-tolerant,  large 
scale,  efficient  system  packages.  A  tool 
which  provldos  tho  ability  to  Tully 
document  and  track  the  development  pro¬ 
cess  of  the  various  modules  within  a 
product  is  one  of  the  several  important 
aids  which  is  needed  to  cope  with  tno 
increasingly  difficult  environment 
within  which  software  packages  are 
currently  being  dovoiopod. 

ni.uV'°  Pseudo  Code  Management  System  i 
!.  will  allow  system  designers  i  or 
Softwnro  Engineers)  to  moro  ofi actively 
document  and  track  sottware  modulos  as 

created.  Tho  system  fits 
well  within  tho  philosophy  of  "Top-Down" 

development  methodology  by  providing  a 
valuabio  tool  to  document,  verify 
completeness  and  maintain  an  nrchivablo 
tracking  method  for  tho  product  under 
roview. 


Tho  life-cycle  model  was  used  to 
manage  tho  development  of  PCMS.  Tho  devo- 
i°K°r^tIn9'  and  maintenance  of 
PCMS  will  be  clone  on  VAX  8530  using  the 

T°POlatl^  systom-  DEC  Ada  Compiler  is 
chosen  to  develop  the  system. 
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The  basic  tea  cures  of  PCMS  are  as 
followings:-  lc  has 

—  on- line  capabilities  co  create,  delete 
,  and  modify  on  each  entry  in  each 
module  template. 

—  capability  to  print  an  entire  module 
template  tor  a  given  module. 


Capability  to  print  only  the  most 
recently  changed  entries. 


Capability  to  reconstruct  a  structured 
chart  graphically  lor  a  given  sub- 
system  (from  the  Informations  provided 
by  the  module  templates  in  the  sub¬ 
system). 


II.  MODULE  TKMPt-nTK  STRUCTURE 


A)  For  each  module,  there  corresponds  a 
module  template  which  includes  Che 
following  entrles:- 

MODULBNAME  :  (modulo  name  or  number) 
FAR70F  :  (subsystem  name  or  numberj 
CALLEDBY  :  (module  name  or  number!* 
PUKPOSES  :  (textual  description! 

DESIGNER/ DATE  :  (designer  and  dace) 
PARAMETER  1. 1  ST  :  (names. modes, attributes!* 
1NPUTASSBRTION  :  (preconditions! 

OUTPUT ASSERT ION  :  (postconditions) 
CAI.MNGFOR  :  (module  name  or  number!* 
GLOBALS  :  (name, mode, shared  with)* 
SIDE-EFFECTS  :  (textual  description) 
LOCALOATA  :  (name, mode. attributes!* 
EXCEPTIONS  :  (conditions, responses!* 
TIM1NGCONSTRAINS  :  (description! 
OTIIERMMITATIONS  :  (description! 
MUDULEBODY  :  (psoudo-codo! 

MODIFIEDBY  :  (whom. when. what. why!* 


*  denotes  zero  or  more  occurrences  of 
tho  entLtios  enclosed  In  parentheses. 


B)  Module  Template  entry  definitions: 


1.  MODULENAME: 

Attributes  :  limited  to  10  charac¬ 
ters  or  numbors 

Definition  :  Tho  modulo  name  iden¬ 
tifies  tho  modulo  temp¬ 
late.  All  references  to 
this  modulo  In  other 
modules  should  use,  this 
neme  to  identify  this 
modulo  template. 


2.  PARTOF: 
Attributes 

Definition 


limited  to  10  charac¬ 
ters  or  numbers 
This  entry  Identifies 
which  subsystem  this 
module  is  part  of. 


:  limited  to  10  charac¬ 
ters  or  numbers 
:  This  entry  identifies 
all  the  modules  which 
call  this  module. 


:  textual  description 
:  A  short  abstract  des¬ 
cribing  the  functional 
purpose  of  the  module. 

5.  DESIGNER/DATE: 

Attributes  :  The  designer  name  is 
limited  to  20  charac¬ 
ters  and  date  is  of 
the  form  MM/DO/YY. 

Definition  :  This  entry  denotes  the 
initial  author  and 
date  of  the  template. 

0.  PARAMETER!,  I  ST : 

Attributes  :  names  -  limited  to  10 
characters 

modes  -  limited  to  IN. 
OUT,  or  INOUf 
attributes  limited  to 
15  characters 

Definition  :  This  entry  Identifies 
all  parameters. 

7.  I NPUTASSERT I ON : 

Attributes  :  textual  description 

Definition  :  This  entry  details  the 
conditions  chut  should 
exist  prior  to  calling 
this  module. 

6.  OUTPUTASSERT ION : 

Attributes  :  textual  description 

Definition  :  This  entry  dotalls  the 
conditions  that  exist 
upon  leaving  this 
module. 

g.  CAM.INGPOR: 

Attributes  :  limited  to  10  charac¬ 
ters  or  numbers 

Definition  :  This  entry  identifies 
all  tho  modules  which 
are  called  by  this 
modulo. 

10.  GLOBALS: 

Attributes  :  names  -  limited  to  10 
characters 
attributes  -  limited 
to  20  characters 

Definition  :  This  entry  identifies 
all  global  variables 
used  by  this  module. 


3.  CAI.LEDBY: 
Attributes 

Definition 


*1.  PURPOSES: 
Attributes 
Definition 


11. 


SIDE-EFFECTS 
Attributes  : 
Dofinicion  : 


textual  description 
This  entry  details  the 
possible  side-effects 
of  executing  the  module. 
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12.  LOCAIDATA: 

Attribute*  :  names  -  limited  to  JO 
characters 

attributes  -  limited  to 
20  characters 

Definition  :  This  entry  identifies 

all  leenl  variables  used 
by  this  module. 


13.  EXCEPTIONS: 

Attributes  :  both  conditions  and  res¬ 
ponses  are  textual 
Definition  :  This  entry  identifies 
conditions  that  would 
cause  an  exception  or 
error  to  arise  and  the 
assigned  response  for 
that  exception. 


14.  T I MI NOCONST KA INS: 

Attributes  :  textual  description 
Definition  :  This  entry  identifies, 
the  time  it  should  take 

for  processing 


15.  MQDUI.EBODY: 

Attributes  :  textual  description 
Definition  :  This  entry  lists  the 
actual  processing  of 

the  module  In  a  stepwise 
manner  using  pseudo  coue 


16.  OTHERl.  IMITATIONS: 

Attributes  :  textual  description 
Definition  :  This  entry  lisLs  the 


functional  limitations 
of  tho  module  which  are 
not  already  specified. 


17.  MOOIPIEOBV: 

Attributes  :  whom  -  limited  to  20 
characters 
when  -  MM/Db/YY 
what  -  limited  to  JO 
characters 
why  -  limited  to  20 
characters 

Definition  :  This  entry  Is  the 

history  of  the  modulo. 


III.  SYSTEM  ARCHITECTURAL.  DESIGN:  - 


...  Digrams  are  used  to  represent 

the  system  architecture.  Tho  overview  of 
the  system  is  ar  ,vn  in  structured  chart 
Figure  1. 


M  « 


With  Text  10; 

With  DirecC.JO; 

Pachnga  PCMS  is 

subtype  NAME_TYPE  is  String! 1. .WO); 
subtype  DESC_TYPE  is  stringtl. . "20j: 
typo  DATEJTYPK  is  new  string! i.  go  * • 
type  PARM_NAMK  TYPE  is  1  ° 

new  stringCl. .00); 

NUMBER_CALLED  :  constant  :•  20- 

NUMHFH“r  lor  a  i'  „constf,n{:  integer':-  20 
uHlJnon— ^ ^ I.OBALS  :  constant  integer: -2 
NUMBKR^LOCALS  ;  constant  integer: -20 
NJMBER__EXCEPTl6NS:  constant  integer:  •! 

constant  integer: -2i 
irJVn0  “^ES  :  constant  integer  :«2l>; 

NUMn7ttAch^neFt..l.  constunt  integer:-: 
NUMBfcR^sUBflODULES: constant  integer: »! 


type  M0DULE_TEMPLATE  Is  record 
NAME  :  NAME  TYPE; 

INDEX  :  INTEGER; 
end  record; 


Each  Modulo_Tcmplate  is  considered  as  a 
record  in  a  direct  access  file.  In  order 
to  facility  the  access  of  tho  direct 
access  file,  a  look-up  hash  table  is  also 
established  with  the  module  name  and  the 
Index. 


- m  h  un  i  Ci, 


typo  M0DULE_DESC  RECORD  Is  record 
NAMES  :  NAME  TYPE*  rd 

MODES  :  NAME~TYPE; 

ATTRIBUTES  :  NAME  tvpP’ 
PURPOSES  :  DESCTV™' 
end  record;  “  ' 
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type  LOCAL  LIST  RECORD  Is  record 
NAMES  :  NAME  TYPE; 

ATTHIBUTES  :KAMK  TYPE; 

PURPOSES  :  DESC_T?PB: 
end  record; 

type  G1.0BAL  LIST  RECORD  Is  record 
NAMES  ?  NAMK_TYPK: 

MODES  :  NAME.TYPK; 

PURPOSES  !  DKSCJTYPR; 

SHAREO_WITH  :  NAMEJTYPE; 
end  record; 

type  EXCEPT ION  JtECORD  Is  record 
CONDITIONS  :  DESCJTYPK; 

RESPONSES  ;  DESC_TYPE; 
end  record; 

type  MODIFIED  BY_RHCORD  Is  record 

whom  :  nKmk^typk; 

DATE  :  NAME.TYPE; 

MEAT  :  DESC  TYPE; 

WHY  :  nKXCjvYPK; 
end  record; 

type  EXCEPT ION_MATK 1 X  Is  nrrny(\.. 

NUMBEK  EXCEPTIONS;  of  EXCEPTION_ 
RECORD” 

type  LOCALS_MATRIX  IsnrrnyCl.. 

NUMBER  LOCAI.S)  ot  L0CAL_I<1ST_ 
RECORD” 

type  GLOBALS  MATRIX  Is  array (1.. 

NUMBER  Cl-OBALS)  of  GLOBAL J. I ST_ 
RECORD? 

type  PARM  MATRIX  Is  array (I.. 

NUMBER  PARM)  of  MODUl.E_DESC_ 
RECORD” 

type  MODIFIED  BY  MATRIX  is  nrrnytl.. 
NUMBER  MODIFIED)  of  MODIFIED  BY 
RECORD? 

type  CALLED  BY  MATRIX  is  nrrnyU.. 
NUMBER"SU0MODULES)  of  MOUULE_ 
TEMPLATE; 

type  CALL  FOR  MATRIX  Is  array (1.. 
NUMBER  SUBMODULES)  of  MODULE_ 
TEMPLATE; 

type  UNIT  RECORD  is  record 
WJDUQLnamE  NAME  TYPE: 
SUBSYSTEM  NAME:  NAME  T^PB; 

CALLED  BY?  CALLED  BY~MATRIX; 
PURPOSES:  DESCJTYPK; 

DESIGN  DATE:  NAME  TYPE: 
PARM_LTST:  PARM  MATRIX; 

LENGTH  PARM  LIST:  Integer; 

INPUT  ASSERTION:  DESC  TYPE; 
OUTPUT  ASSERTION:  DESCJTYPE; 

CALL  FOR:  CALL  FOR  MATRIX; 
GLOBALS:  GLOBAUS  MATRIX; 

LENGTH  GLOBALS  LIST:  Integer; 
SIDE_EFFECTS:  PESO  TYPE; 

LOCAL  DATA:  LOCALS_MATRIX, 

LENGTH  LOCALS  LIST:  integer; 
EXCEPTIONS:  EJfCEPTION_MAfKlX, 


T IM l NC_CONSTRA INS  :  DESC  TYPE: 

LIMITATIONS  :  DESC  TYPE: ”* 

PSEUDO  CODE  :  UESCTYPE: 

MODIFIED  BY  :  MODIFIED  BY*  MATRIX; 
LENGTH_m5d_MATR I X :  Integer; 
end  record; 


Datn_Base_Rec  :  UNIT_RECORD; 

type  Record_Index  Is  range  l..  MAX_MQDULK; 

type  Unlt_Rcc_Veet  is  array (Record  Index) 
of  UNlT_RECORD; 

Dat«_Base_Ve«t  ;  Uni c_Roe_Vect; 

packago  Database  10  is  New  Direct  lOi 
UNIT^RECoRD); 

Use  Datnbaso_IO; 

Data_Base_File  :  file_type; 

f  ;  Databaso^lO. fiio_type; 

package  INTJO  is  New  Integer_IO(  integer); 

Use  INT.IO; 

type  LOOKUP  TABLE  Is  array (1..  NAX_ 
MODULES)  of  MODULEJEMPLATE: 

IIASH_TABLE  :  LOOKUPJfABLB; 


Procedure  Display  Menu 

(Menu_Nu»ber”:  IN  NAMK_TVPE); 

Procedure  Display  Modules 

l Roo  t_Mod u  1  ct~N amo :  IN  NAMKJTYPE); 

Procedure  PrInt_Modulos; 

Procedure  Initial  I-/o_DtjtnJ)ase; 

Procedure  Create_Modulo 

(Modulo_Na*e  :  IN  NAME_TYPB) ; 


Procedure  Delete  Modulo 

(Modulo_Nnme  :  IN  NAME_TYPE); 


Procedure  Modify  Module 

(rtodulu_Namo  :  IN  NAMEJfYPE); 


Procedure  Search  For  Module 

(Modulo_Name  :  Tn  NAME  TYPE; 

Hash  Index  Number:  OUT  integer; 
DataBaso_lndex:  OUT  integer); 


(Nodule-Name:  IN  NAME  TYPE; 

Coll  By_Vect:  OUT  MODULE  TEMPLATE- 
CallFor_Vect:  OUT  MODULE  TEMPLATE)- 
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Procedure  Allocate  Module^  „ 

(Module  Name:  IN  NAMR.TYPB: 

Indexjhimber:  OUT  Integer).* 

Procedure  UcaUecale Mtviule 

(indexjhimber:  IN  integer): 

Procedure  ReadJJacaJlaxe 

l Location  :  IN  Integer): 

Procedure  Write  Data  Rase 

(Location  :  IN  Integer); 


end  pais: 


Thu  detail  design  o(  the  major  runetiena 
for  the  PCMS  will  be  described  in  pseudo¬ 
code*  In  the  next  section. 


IV.  DETAIL  DESIGNS 

).l  Editing  subsystem: 

Procedure  CrenteJIodulo 

begin  ,  . 

Search  For_Nodulo 
if  module  does  not  exist  tlien 
boom 

Cot  Information 
Al  1  ocate_Spnco^Kor J-lodu  1  e 
Sec  Link  Called 
WriCa_Kecord  to  database  file 
end 

olse 

print  error  message 
end  if 
end: 

Procedure  Modiryjrtodulo 
begin 

Scarch_Kor  Modulo 
If  module  Hoes  not  exist  tnen 
print  error  message 
clsa 

begin  ,  , 

read  module  Into  butTer  record 
display  menu  , 

road  the  chosen  field  from  the 
buffer  record 
display  the  field  on  ert 
enable  editing 

rS£°.“°t~' 'UMiyfi.U  to  thr. 
database  file 

end 

end  if 
end 


Procedure  Delate_Module 
begin 

Search_For  Module 
If  module  does  not  exist  then 
print  error  message 
else 
begin 

read  module  into  a  buffer  record 
from  database  ftlu 
assign  CALLED  Ji¥  field  to  « 
temporary  location 
assign  L*ALL_FOR  field  to  a 
,  temporary  location 

fro"  tl,e  l,ash  table 
{Jt^J-WCATEjyvLL^UV.HePURKNCE 
DEAU.OCATE^CALLJKOK  REFERENCE 

fcftif 
end  If 
end 

Procedure  ifearch..F©r_Module 
begin 

initialise  variable  RESULT  to  zero 
search  the  hash  table  until  a  module 
with  given  name  found 

if  found  then  assign  the  pox l cion 
where  It  was  lound  to  RESULT 
and  then  exit 
end 


Procedure  Al locate_Spnes_For_Module 
begin 

Initialize  RESULT  to  zero 
H  TABLE  SIZE  greater  than  MAX  MODULE 
allowed  then  raise  exception 

^RESULT0  K 1  KijT-AVA  1  ^DLK J»OS 
end  i  r 

P“UhSh  l«m.X  ,ln,Ch?  corresponding 
naxn  table  and  the  MODULI-*  N amp  in 

riol<i  °r 

search  the  hash  cable  until  the  next 
first  available  position  found 
assign  that  value  to 

FIRST_AVAI  LADLE  POS 
end 

Procedure  Set_I.Jnk_Cal  led 
begin 

assign  CALLKD^BY,  CALL^FOR  and  the 

length  of  each  Held  to  a  temporary 
location 

for  all  the  element  in  the  CALLED_3Y 
field  loop  “ 

got  the  record  corresponding  to  the 
element  from  database  file 
search  through  its  CALL  FOR  field 
until  an  empty  position  found 
assign  the  file  index  of  current 
module  template  to  that  Index 
position 
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write  the  record  back  to  the  file 


end  loop 

for  nil  the  element  In  the  CW,i.-KOH 
field  loop 


eet  the  record  correspond In?  to 
the  element  frow  database  tile 
search  through  Its  CALLKUJiV  field 
until  on  er-pty  position  round 
assign  the  file  Index  of  the  eurret 
module  template  to  that  position 
assign  the  module  name  to  the  name 
field  of  that  position 
write  the  record  back  to  the  tile 


end  loop 
end 

Procedure  eec_lnformatUm 


^get  information  of  each  field  f)  t,ltt 
module  template  from  the  screen 
interactively 
end 


2.0  Printing  subsystem 


Procedure  Prlnt_A_ModuW 


begin  ,  . .  . 

print  each  field  oi 
one  by  one 

end 


the  module  template 


Procedure  Pr i ntjMod i. f i edJEntr i os 

Sprint  all  che  fields  that  have  been 
changed  by  chocking  each  field  ring 
end 


draw  the  horizontal  line  connecting 
the  first  cal  lee  and  last  callee 
draw  vertical  lines  lor  each  callees 
else 

draw  a  vertical  line  connecting  che 
module  and  callee 
end  if 
end 


Procedure  hraw_tloduie-Name_l.lst 
begin 

for  all  the  modules  loop 
draw  the  module  number 
draw  the  module  name 
end  loop 


Procedure  t)rnw_A_Treo 
begin 

for  the  number  of  queue  items  loop 
Draw  box 

If  tfie re  are  cal  lees  then 
Draw  connection Lines 
end  if” 

keep  record  of  the  last  row  mtmber 
end  loop 
end 


Procedure  Vlew_and_Mova 
begin 

initialize  first  row  nnd  rtrst  column 
loop 

Display^On  Screen 

display  move  choice  and  get  choice 
if  choice  is  to  exit  then  exit  loop 
else 

change  first  row  and  column  accord¬ 
ing  to  the  choice 
end  loop 
end 


J.O  Display  subsystem 


Procedure  Cirnw_Uox 


begin 

calculate  the  row  and  column  of 
the  module  box 
draw  che  modulo  box 
If  the  modulo  calls 
draw  the  recursive  module  lines 

end 


Procedure  Dcaw_Conncction_bines 


^calculate  row  of  the  connection  lino 
if  more  than  one  cal lees  then 

calculate  the  columns  of  the  first 
and  last  callees  of  the  module 


Procedure  Pi nd_Rccurs i vo_Modu 1 o 
begin 

for  all  modules  loop 
find  MODULE  INDEX 

for  all  callees  of  the  module  loop 
if  the  modulo  calls  itself  then 
mark  the  modulo  recursive 
end  loop 

if  the  modulo  is  recursive  then 
removo  the  recursively  called 
callee  from  the  calicos  coble 
end  loop 
end 


Procedure  Up_Trodng 
begin 

initialize  the  up  tracing  queue  index 
to  the  rear  of  the  queue 
while  the  up  tracing  queue  index  is 
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not  Uta  top  of  the  tree  loop 

initialize  the  left  tt*c(ns  qv  % 
index  to  the  left  pointer  of  ..«« 
up  tracing  queue  index 
while  Module  pointed  by  the  left 
treeing  queue  index  exists  loop 
add  the  left  most  eel  lee's 
relative  column  position  of  the 
Module  pointed  by  the  rear  queue 
index  Co  the  relative  position 
of  the  Module  pointed  by  the 
left  tracing  queue  index 
Move  the  left  treeing  queue 
index  to  the  left 
end  loop 

initialize  the  eight  tracing  queue 
index  to  the  right  po inter  of  the 
up  tracing  queue  index 

while  Module  pointed  by  the  right 
tracing  queue  index  exists  loop 

add  the  right  Most  catlee'x 
relative  column  posic<on  of  the 
Module  pointed  by  the  rear  queue 
Index  to  the  relative  position  of 
the  Modulo  pointed  by  the  lelt 
tracing  queue  index 

Sv?i4"“e}Sa  cr“cl'” 

end  loop 

*°theCcall,QrLr,,Cin9  t,ueu®  lndox  Lo 
end  loop 


Procedure  Cal  j\bsoluto_KodulojPoxlcion 

begin 

for  all  cho  queue  i tests  fro«  roar 
to  front  loop 

caller  then 

£“***  c«ler*s  absolute  column 
hnif  ^ee"  calculated 
before  to  this  Modules  relative 
column  position  to  make  the  column 
position  absolute 
else  no  calculation, 
the  relative  column  position  is 
also  its  absolute  column  position 
end  if 
end  loop 
end 


Procedure  Bui ldJJp_Quouo 
begin 

initialize  queue  front  and  rear  to  1 
the  layer  position  of  the  first  queue 
item  is  1 

assign  the  module  index  and  module 


nfiTwAsr  "*“*>«  »  u» 

2rf‘“rs  Mv®  sr 

$Tt 2%  2  a  S2i* 

°r  Um  hueue  by  , 

«»«;{!*•  ch«  J«yer  and  column 
item  °n  c*,e  front  queue 

M winter  of\h«*r,ofc'  rl^ 

itn  co  *« 

end  loop 

«•« «* 

*  tho  ro«ir  of  M 
C«  )_Abso  1 uto_nodu  1  Ic  ion to  1 


begin 

C°Sles  o?then?  U’°  nU^r  Of 

rfixplay  the  module”sCm^dui  „ 

prS»J  • odoi®  name  ™dUl°  nUwbor 
SS&leMuffi  to  »«*  the  root 

czr°  th° root  *odui-'s 

end 

Procedure  Read_Datajiaso_Pi>Q 
begin 

read  the  record  ?°^ufcs  loop 
wdulo  indox°of  th^hn1!!9  the 
assign  tho  0  hnsh  tab  Jo 

fndex,  nuSbor1ofn^nr'mo<lul0 
the  modulSTit^  rie]d  of 

of  the  record  fcho  values 

fa  for 
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eaehcallce  with  the  value  of  Uks 
record 
end  loop 

end  loop 
end 


Procedure  0i8ptnyj>U'ueture_Ch«ri: 


read  files  co  9©t  number  of  nodules. 

hash  (.able  and  nodules 
find  recursively  called  nodules 

do  until  user  wanes  co  exit 
loop 

ttenu.and  Gec_Choice 
ease  choice  of 

1.2:  to  display  structure  chart 
If  choice  -  1  then 
»ulld_Up_Qoeuo  tor  Ute  whole 
system  “ 
else 

Display  «odulo„Usc_and_ 

Cet  Hoot  Module_lndes 
build  Up_tlueue  starting  tides 
the  root’Vodule 
end  If 
Draw  a  tree 
D  raw“«odu l e_NnneJ,  1 8 1 
Vlew"And_«ove 

enable  to  print  the  structure 
chart 

3  :  If  the  structure  chart  Isas 

been  drawn  then  print  It 

4  :  exit 
end  case 

end  loop 
end 
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V.  CONCLUSION 


The  PCMS  will  help  the  systen  de¬ 
signer  (or  software  engineers)  to  noro 
effectively  document  and  track  software 
nodules  as  they  are  being  created,  it 
Is  also  a  valuable  tool  to  document, 
verify  conpleteness  and  maintains 
archlvlnble  tracking  method  for  the 
product  under  revlow. 

With  the  Pseudocode  In  each  Module_ 
Template,  tho  source  codes  In  Ada  will  bo 
ensily  developed,  and  "}* 

system  will  bo  more  easy  to  maintain. 
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Summary 


Thi*  (tapir  describe*  a  data  reductfen  method  that  automaltcallv 
correlate*  4*i*  prtaluced  by  Ada  source  rodr.  TV  method  m- 
ploy*  *  unique  iUu  reduction  builder  program  Out  u»e*  Ada 
generic*  14  Solve-  the  confifUratloet  Control  problem*  »*u-ci»ied 
with  data  reduction  tn  nutty  targe  systems.  Tbe  presented 
method  general**  Ada  generic  ln*tan!utiOn*  (4  support  the  Core 
function*  needed  by  the  data  rodogtion  analysis  software  19 
procr**  recorded  data.  THU  mat H<xl  Involve*  the  recognition  of 
recordable-  data  structure*  by  using  identifier*  embedded  in  tb« 
Ada  source  code.  Thu*  an  automat'd  binding  of  lb«  data  *truc 
turn*  occur*  between  tbi  Ada  source  program  and  lb*  data 
reduction  analysl*  system. 

Overview 

A  major  pruWitn  in  reducing  tbi  va*t  amount  of  data  that  a  largi 
Kali  system  prods***  it  an  inability  to  automata  thi  correlation 
of  tbi  output  data  with  tbi  sourt*  rod*  that  generate*  it.  Data 
redoetton  *oftw*r*  typically  ia  written  after  all  tbi  data  at  torture* 
of  the  system  Have  been  developed,  and  tbe  software  run*  a*  a 
separate  program.  A  correlation  between  tbe  two  program*  mutt 
ilitt  regarding  tbc  definition*  of  tbe  recorded  data  *0  that  data 
analytic  function*  can  be  performed.  In  a  development  environ¬ 
ment,  *ource  code  often  undergo#*  debugging  and  letting,  and 
change*  involving  data  structure*  and  data  output*  are  routinely 
made  to  tH*  aource  toftware.  Often  tbe  corresponding  change*  to 
tbe  data  reduction  toftware  are  inadvertently  neglected.  THit  tan 
create  a  configuration  control  nightmare. 

lly  enforcing  a  detign  ditripline  on  thi  Urge-Kale  tyttem  that 
require*  an  Ada-type  definition  for  each  recordable  data  slruc* 
lure,  thia  configuration  problem  can  be  eliminated.  In  addition  to 
an  AtU  compiler  and  a  ho*l  computer  operating  *y*tcm,  three 
major  aoftwate  component*  to  be  considered  In  describing  thi* 
method  art:  111  The  AtU  source  toftware  that  produce*  recorded 
data,  (2)  the  data  reduction  builder  software,  and  (31  the  data 
reduction  analytic  toftware  that  illustrate*  the  relatlonthip  of  one 
component  to  toother. 

Source  Software  for  Recorded  Data 

Aa  thown  tn  Figure  1,  the  data  reduction  builder  toftware  acetate* 
tbe  Ada  tourct  software  of  tbe  large  Kale  tyttem.  The  data 
reduction  builder  toftware  identifiet  the  recordable  data  struc¬ 
ture*  and  generate*  a  tynibo)  table  that  represent!  the  data 
structure*.  By  taking  advantage  of  Ada'*  generic*  feature,  the 
data  reduction  builder  generate*  Typ*-Speri(ic-Ad*-Sourte 
-Code.  Thi*  TVpe-Specifie-Ada-Source-Code  form*  the  core 
function*  of  the  data  reduction  analyst  toftware.  The  Ada 
compiler  link*  the  Type-Specific-A  da-Source-Code  with  the 


source  code  that  comprise*  the  framework  of  the  data  reduction 
analyst*  software  and  produce*  an  etecutable  program.  The 
txcutable  program  will  reduce  and  analyte  the  recorded  data 
produced  hy  the  large  Kale  system.  Thi*  automated  source  code 
eit  r action  and  *span*hm  capability  solve*  the  configuration  man¬ 
agement  problem  of  correlating  output  data  with  tbe  source  code. 

Data  Keduetiou  Builder 

Tbe  Ada  source  software  for  tbe  large  Kale  sy»tem  that  produce* 
recorded  data  i*  proceSaed  by  tbe  data  reduction  builder  in  much 
the  same  Way  as  a  compiler  processes  source  code.  However.  In 
the  case  of  the  data  reduction  builder,  the  only  thing  it  i* 
concerned  with  is  to  identify  recordable  data  structure*  and  to 
generate  Type.Speclfic.AdaJfeurce.Code  to  process  the  data 
structures.  For  each  Ad*  type  used  to  define  recorded  data 
structure*  in  tbe  Ada  source  software  for  the  large  Kale  system,  a 
procedure  instantiation  is  generated  with  that  type  declared  aa  tbe 
actual  parameter  to  be  associated  with  tbe  generic  formal  param¬ 
eter.  Tbe  Type-SpeCificw\daJfeuK».Cod*  Is  placed  Into  an  Ada 
library  and  provide*  the  core  function*  of  the  data  reduction  and 
analysis  system.  Figure  3  illustrate*  tbe  major  function*  per¬ 
formed  to  generate  tbe  tore  function*  of  the  data  reduction  and 
*naly*i*  system. 

Data  Keduciian  and  An»!y*i*^Sy*teiu 

Tbe  data  reduction  and  analyst*  system  provides  an  interactive 
user  interface  to  analysis  procedures  that  access  recorded  data 
contained  in  a  data  Uue.  The  Type -Specific  .A  da -Source-Code 


Figure  1:  Data  Reduction  Support  Environment 
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Cure  funttien*  *upport  data  have  Mtvkw  u**d  by  the  »n*I-»»* 
procedure*.  The  data  b#«*  Kni,‘t»  Witte  function*  «xh  a*  the 
inrital  data  We  definition  and  toadinc  ef  the  raw  recorded  data. 
TV  raw  fwefiWt?  data  i*  reptv*entvd  m  the  f arm  of  taverner*,  of 
vnrw*  Know«.Type*.  Ficot*  3  ittu.|ratc*  the  m»|or  precc**iny 
function*  involved.  The  eoftware  generated  be  I  be  Data  Reduc¬ 
tion  HmM»r  maudy  pitmen*  the  D*t*  Reduction  Data  IWe 
Service*. 

Detailed  DetCfij-lw-n 

Ada-Tyfe  Definition. 

For  ihi*  method  is  be  acceptable.  ibe  impact  on  tbe  Ada  *ource 
that  produce*  recorded  data  mu.t  be  minimal,  Within  lb®  AtU 
route*.  *  dedicated  Ada-rype  definition  l*  teeprited  fee  each 
recordable  data  Mructure,  The  method  u*ed  w  identify  each 
recordable  dat*  Mmctut*  *•  levied  fey  tfei*  dc.ign  retire*  a  Key 
character  rtriftg  in  ptefi*  lhe*«  Ada-type  name*.  An  alternate  in 
ibe  r>l»feli‘h»enl  of  a  ptefi»  naming  convention  i*  in  teeprite  ibe 
developer*  of  recordable  data  Mructure*  in  regitter  ibe  Ada-type 
name*  of  ibe»e  Mructure*  with  ibe  data  reduction  builder.  The 
Ada-type  name  nf  each  recordable  data  Mructure  would  be  teyl*. 


Figure  2.  Overview  of  Data  Reduction  Builder 


Figure  3.  Overview  of  Data  Reduction  and  Astalyaia  Syitem 


leted  by  placing  U  into  nn  enumeration  literal  epecificawon,  Hie 
enumeration  type  that  define*  all  recordable  dal*  .tructute* 
would  be  ti*ed  in  guide  ibe  <Uu  reduction  Udder  in  determine  Ibe 
dal*  Mructure*  in  piece**,  Tbe  dt*«b*<k  In  ihi*  approach  i<  lhal 
ibe  certainty  factor,  that  name*  in  Ibe  enumeration  type  maitb 
tbe  name*  of  Ibe  type  definition*  for  recordable  data  Mructure*.  U 
reduced  because  of  ibe  human  activity  Involved.  A  tradeoff 
derwion  i*  in  be  made  h»t»«efl  tbe  reMriction*  tmp«a*d  by  ibe  u*e 
Of  a  naming  convention  ver*u*  ibe  added  Uytr  Of  auiomaitd 
configuration  control  gained  by  not  wring  a  manually  maintained 
tt»t  bf  name*. 

Another  requirement  placed  on  Ibe  *ource  code  by  ibe  dale 
reduction  builder  I*  that  ll  mu*l  be  pbiCed  in  an  Ada  library,  which 
infer*  that  it  ba*  been  compiled  error-free,  TW*  relieve*  ibe  data 
reduction  buttdei  of  performing  error  checkin*  ibat  otberwiee 
would  be  needed. 

A*  input  Ifc  the  data  reduction  builder,  ibe  uter  mu*l  *pec(fy  ibe 
name  of  ibe  Ada  program  ibal  produce*  c-wrded  data  and  lu 
program  library  The  u*er  aUc  may  *»Wci  compilation  and  link 
option*. 

The  initial  out  of  Ada  *ource  code  p»oce**in<  peiformed  by  ibe 
data  reduction  builder  i*  In  irarufer  all  data  *tmctilre  definition* 
into  a  te.uof-All.Type*.  TbU  require*  ibe  recofnition  of  ibe 
Ada  data  type*,  which  an>  defined  a*  ibe  aoc»**  type,  army  type, 
private  lype,  record  type.  *calar  type  Iwbkb  Can  be  a  di*crele  lype 
or  re»l  type),  and  ibe  eubtype.  Repreeentaiioe,  epectficallon*,  and 
any  urn  of  ibe  predefined  lanyuaye  pragma  BACK,  amaeiaied  with 
lbe*e  type*  muH  al*o  be  eatracted  from  ibe  Ada  *aurce  code. 

ttcpreieniattveSjpecification* 

It  it  aaautaed  that  ibe  pbyrical  eintclure  of  a  recorded  me**aye  l* 
controlled,  ritber  ihrouyb  the  defacin  Mructure  provided  by  lb« 
Ada  run  time  environment,  throuyh  the  u*e  Of  Ada  r«pre*eniailon 
epecification*.  or  ibrouyb  u*e  of  the  predefined  lanyuaye  prayma 
BACK.  One  important  conridemiion  i*  that  when  Ibe  *y*iem  that 
produce*  ibe  del*  u*e«  different  device  driver*  from  Ibe  *y*lem 
ibal  analyte*  ibe  data,  a  poMibility  for  incon*S*t*ncy  *»i»t*.  Tbe 
u*e  of  Ada  tvpreeenlaiion  apecificaiion*  in  Ibe  Ade  proyram  Ibat 
produce*  recorded  data  Only  affect*  the  core  function*  Ibat  handle 
recorded  data  input  to  tbe  data  analytic  Mftware.  The  method 
u*ed  to  handle  a  tepretentatlon  apedficatlon  for  a  type  U 10  copy 
it  from  ibe  Ad*  proyram  that  produce*  ibe  recorded  data  and 
place  Si  In  the  type  declaration*  for  ibe  data  analytic  procedure*. 
The  **me  proceariny  it  alto  true  for  u*e  of  the  predefined 
lanyuaye  prayma  BACK  a*  it  applie*  to  recordable  data  »t nur¬ 
ture*. 

Symbol  Table  Renetaior  Kuntlicn 

Tbe  lymbol  table  ycnerator  function  Involve*  creation  of  a  te.t- 
-of.Known.'fVpe*  data  ttructure  that  define*  all  of  the  lype 
dependeacie*  of  each  Known-Type.  In  lhl«  conteit,  a  Known 
-Type  I*  Ibe  name  yiven  10  the  Ada  type  for  an  Identified 
recordable  data  Mructure.  An  Applicablc.Type  U  a  type  depen¬ 
dency  that  muM  be  defined  in  order  for  the  compilation  of  a 
Known-Type  to  be  correct.  Rech  Applicablc.Type  alto  yeu 
defined  in  the  Utuof.Known.Type*.  Fifure  *  lliuitrate*  the 
proce«*iny  element*  involved  with  creation  of  the  Utuof 
-Known-Type*. 

The  Utuof-Known-Type*  alto  contain*  link*  that  rtprttent  the 
aaiociation  of  type*  In  tbe  Ada  proyram  that  produce*  recorded 
data.  Backwardt  link*  between  a  Known-Type  and  all  of  it* 
Applicable-lVpe*  are  generated.  A  backward*  link  from  each 
Applicablc.Type  to  all  of  it*  Applicable-Type*  I*  yeneraied. 
Forward  link*  from  an  Applicable-Type  to  all  of  the  Known 
-Type*  and/or  other  Applicable-Type*  that  refer  to  It  are  al*o 
generated.  The  purpote  of  generating  all  of  there  link*  it  to 
•upport  the  Ada  code  generation  Mage  of  the  data  reduction 
builder  and  to  (upport  an  interactive  type  analytit  function. 
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TV*  mmt  cod*  penerMor  u»**  the  UM.©f  .KnuwvTyp**  <0 
produc*  Ad*  t*>d*  for  procedure  ApenfoMAm*,  typ*  Afuwtxn*. 
**>4  iftMftntlMiOn*  for  KlWWft.Typr*. 

Foe  eat  h  Kmr.ft.Typ*  and  for  «li  Appi*e»bl*.Typ*.  AAt  tod*  i* 
irnn*r  ated  t©  tfovUf*  procedure  *p*vtfAtM><©»*  for  **ch  ©I  lh«  type 
epecific  owe  function*.  TK*  typ*  *p*ci6<  cor* /unci***  •uppori 
©perMton*  *uch  <m  lb*  following; 

l.  Declare  lit©  Known,  Tjp*  and  Appik»bi*.Typ*  dM* 
UNflW 

i  <?**m«  *  Ah*  ba*«  1©  contain  recorded  Ah* 

A  Transfer  w^nW  Ah*  from  the  large  AC*t*  AyMemV 
elofag.  Audi!  iht©  tb*  Ah*  b*w 

4.  Retrieve  twweM  Ah*  front  the  tUt*  b*** 

5.  Star*  recorded  Ah*  into  the  Ah»  baa* 

In  addition.  for  e*ch  Kw»#.T)ih  *©4  each  Appb<*bie,Typ». 
Ad*  code  H  generated  I©  output  lb*  character  Mriog  tbM  i*  iW 
matter  twV  name  of  the  type  Thw  i*  u*»d  by  lb*  eoflwart  (Km 
di*fUyx  lb*  recorded  Ah*  i©  tdrattfy  the  Ah*  in  the  context  of  »(« 
original  Ah*  atruclur*  deftniiion. 

Fnf  each  KtWwfl.Typ*.  Ad*  ©ode  t*  4*©  gMtrfMed  I©  decUl* 
ioMsntiMioo**  ©4  gmeric  port*  Ain*.  which  *1*  **dn#qu*n«ly 
creMed  by  th*  compiler  *itd  become  part  ©4  the  library.  Ad* 
matter  r«d*  i*  alto  i^tented  19  creMr  1*9  mume  rated  type*:  on* 
l*  th*  type  Co re  Function*.  which  contain*  enumeration  bt*f»l« 
1  Km  identify  rath  owe  function.  the  other  la  in*  typ*  Known- 
-Typ»*.  which  identifi**  each  of  the  Known.Typ*  name*  (Km  in 
1  urn,  identify  the  ncotAAW  Ah*  Mfuciun*.  Th*  tv©**  Cote- 
.Function*  and  Known/Type*  *rr  u**d  in  OHnbinMioo  by  >K« 
Ah*  reduction  *nd  *n*!y*i*  pructdun*.  10  invoke  the  come  fune- 
lion*  on  a  type  name  Wi*.  Source  cod*  l*  aUu  generated  to  define 
**ch  Known.Tjyte  *nd  *mK  Apfdkddv.Tjv*  (K*t  yi^v*  vtoiitiliiy 
of  lKo*r  MOKfumi  (o  iK*  Am*  odooton  *nd  on*Jyw*  ma(\w*rt. 
At  nwnttoofd  **rlkr,  for  r*o>rAAW  Ah*  Mructur**  (iho**  idrn< 


lifted  »*  *  Kno»n«Typ*i  »»-*  K*v*  »n  ***©<iiH»4  Ad*  (*(>(*©{©• 
(•lion  tfMifkMion,  *  tvfsygf  (K*  fTpry—niMion  tfrrifitMtrm  i* 
j4m»4  in  hHK  iK*  Kn*>*n«1V|i«  Arfiidiion;  iKi*  *l*o  *pflW»  10  *** 
of  (Kf  predrAned  Unjo***  fttttpm  I'ACK. 

An*lj»U  i*n*»du»** 

H***d  ©n  iK*  tar  of  iW  one  Ahkihm*  y*n»rM*d  Ky  iKe  dM* 
ledortion  KoiUtr.  Ah*  W*  wokt*  f*n  K*  *M*KlUK*d  w  niKo* 
*n4j>M  jnorodoreo  lo  fMifom  foncitow  on  »K*  Ah*.  TK*  Am* 
K***  trtrkr*  |novid*  »n  im»rf*r»  «o  lyp*  tpoifx  toot  Amrlton*: 
*  Moke  r*n  K*  invoked  0*  *  prw*durt  (Km  «•*«  tnunwrMed 
lypM  l»  KWniify  iK*  Known.Tlri1*  *nd  function.  TK*  ©*©M  Wk 
funciion  eoppotied  Ky  lK<  »n*iy»i(i  orwrAirv*  i*  10  •Mom  okooW 
Ah*  10  K«  vko*d  vdtK  (K<  retpevliv*  M**rc*  rode  Ah*  MnKture 
Afmdron  t»*ed  10  deMtifce  iKe  Aha.  An  ioitmetive  (Her  iMerf*<e 
(Km  nutVe*  u*e  of  v>indo«A.  a  moot*.  And  poll. down  menu*  i*  * 
deMr*We  worKriMion  coniWonHion  for  inierwciiv*  Aha  ***o*inA> 
Iron,  *nd  (Ke  »e«e»Mron  of  Kord  copie*  of  reorrded  Ah*  k  »Uo 
ropporled. 

A  am  Kef  Aordyd*  prweduf*  iKm  t*«  Ke  euppuHed  Ky  iKe  tori 
fontifon*  i*  *n  inier*titve  d*(*  lyp*  (r*re'fofw«rd  lr»t«« 
K*<Kw*rd  look  TKt*  *ifow*  *  u»ef  10  etamine  AOOIte  rode  dM* 
MAKiurt  defindron*  (Kmu«K  4i  level*  of  lype,  M*U)pe.  letord, 
*nd  orr*y  d*r«nt(ron*,  KmK  10  iKe  primHWe  Ama  Hmciore  el*' 
rnet>(».  !>«  I  nxe- forward  prrknl*  iKe  (Her  wdK  oil  lype*  iKm 
u*e  *n  AppUodde -Type  in  iKeir  deirnilion.  TK*  IdM.o/.Known 
Type*  tfeMed  Ky  iKe  Aha  reduction  builder  U  (be  Key  element  for 
iKu  (eMure.  *nd  mrnrt  a  function  MmiUr  10  |K*(  of  *  Aha  ho** 
AC  Kern*. 

TK*  default  mode  of  ditpUy  for  A  dM*  object  u*e*  a  H*nd*rd 
nwppin<  to  lb*  type  definition  in  (K*  eource  rode.  TKi#  include* 
lb*  u*e  of  enum*r*lion.lit*t*i*  lo  define  the  vabr*  of  on  enumef 
Med  lype  TK*  u*«r  C*n  Aelect  Other  formM  option*  from  A  l«M  in 
II  pull -down  menu  10  v$*w  *  iUt*  object. 

Another  tniereHinit  ft*p*tt  of  iKi*  method  i*  lh*l  the  Aha  reduc¬ 
tion  builder  c*n  be  UAed  hi  (enetM*  Ad*  aoAwatc  to  An*lyw  if* 
own  Aha  Atructure*.  TKi*  KoM*tr*p  npproncK  to  le*ltn*  i* 
convenient  bec*u*e  It  doe*  not  require  the  Ur**  *c*l*  tytlem  iKm 
product*  recorded  dot*  to  be  completed  before  complex  doi* 
Atructure*  c*n  be  uted  m  lo*t  c**e*  for  (he  d*(*  reduction  ond 
ftnalyeit  AVAiem.  TK*  ut*  of  Ad*  generic*  *!*o  ho*  (he  ohviou* 
advunlftge  (Hm  rhonge*  10  (he  core  function*  or  (he  inclution  of 
»ddili09*l  core  function*  only  requit*  cK*ng*«  lo  ’He  generic 
bodit*  for  primillvo  Aha  lype*.  Tettlngof  the  core  function*  *lw 
only  need*  10  b«  performed  on  the  primitive  d*U  type*. 

Kiample 

Ceing  *n  Adx  Aha  wruciurr,  *ome  fcAiurr*  of  an  inieraciive 
recorded  d*t*  examinalion  loot  will  be  preAented.  TW*  100I 
nuke*  ui*  of  the  core  function*  lh*l  the  D*l*  Redotlion  Builder 
generale*.  A**ume  Out  «  d*ia  Atructure  ha*  been  recorded  by  a 
procrM  that  monitor*  cammunicAtioni  bu*  activity  in  tire  large 
Acale  »y*um.  AI*o  ***ume  that  a  uttr  ha*  been  able  to  telect  thi* 
data  Atructure  for  *n*ly*I*.  The  recortled  data  Atructure  include* 
me***gt  Iteader  information  containing  the  me***ge  identifier 
twliicb  1*  it*  Ada  type  identifier),  a  timettamp,  and  po**ibIy  the 
*cm!er  and  intended  receiver  of  the  me***ge;  the  header  I*  not 
defined  **  part  of  the  example. 


Figure  4.  Symbol  Table  Generator  Diagram 
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package  aample_struct ure  is 
—  Data  Structure  Definition 

typ-^  L,AN__NOD£_ID  is  range  0  .  .  1024  ; 

type  PERIPHEP.ALS  is 

{  D I SKYCAP  , 

SHARED_RAM  , 

DISPLAYS  , 

PRINTERS  )  ; 

type  PROCESSORS  is  \  MicroVAX,  Macintosh  )  ; 

type  SYSTEMS  is  {  A_SYSTEM,  B_SYSTEM  >  ; 

typ  *.  <  '^FIGURATION  is  array  (  PERIPHERALS  )  of 
JiEGER  range  0  • .  10_000  ; 

type  NETWORK  is  array  (  PROCESSORS  )  of 

INTEGER  range  0  . .  100  ; 

type  SYSTEM  RECORD  is  record 

PRIMARYJtD  ,  SECOND ARY_ID  :  LAN_NODE_ID  ; 
DEVICES*:  CONFIGURATION  ; 

CPU_LEFT  :  NETWORK  ; 
en  .i  record  ; 

type  SYrT£M_STATUS__MESSAGE  is  array  (  SYSTEMS  ) 
of  SYSTEM  RECORD  ; 


SYSTEM  ID  :  SYSTEM  STATUS  MESSAGE 


A_SYSTEM  »> 

PRIKARY_ID  »> 

100 

(  o  ) 

SECONDARY  ID  «> 

200 

(  1  ) 

DEVICES  »> 

DI SKYCAP  => 

1000 

{  2  ) 

SHARED  RAM  »'> 

90C 

(  3  ) 

NODES  *  «> 

200 

(  4  ) 

PRINTERS  ■*> 

50 

(  5  ) 

CPU_LEFT  -> 

MlcroVAX  «> 

50 

(  6  ) 

Macintosh  *> 

;  15 

(  1  ) 

E_SYSTEM  -> 

PR1MARY_ID  «>.. 

300 

(  8  ) 

SECONDARY  ID  «> 

400 

(  9  ) 

DEVICES  *> 

D I  SKYCAP  «> 

5000 

(  10  ) 

SHARED_RAM  -> 

2000 

(  11  ) 

NODES  »> 

1000 

(  12  ) 

PRINTERS  *> 

250 

(  13  ) 

CPU_LEFT  «> 

MicroVAX  ■> 

45 

(  14  ) 

Macintosh  *> 

20 

<  15  ) 

type  SYSTEM  RECORD  is  record 

PRIMARY  ID, 

SECONDARY_ID 

:  IAN  NODE  ID  ; 

DEVICES 

:  CONFIGURATION 

CPU_LEFT 

:  NETWORK  ; 

end  record  ; 

--  Data  Structure  Initialization 

SYSTEM_ID  :  SYSTEM_STATUS__MESSAGE  { 
aJsYETEM 

(  PRIMARY  ID  ->  100  , 

SECOLDARY_ID  200  , 

DEVICES  => 

<  DI:JK_CAP  *>  1000  , 

SHARED_RAM  «>  900  , 

NODES  *  «=>  200  , 

PRINTERS  «>  50  )  , 

cpuj.  :ft  -> 

(  Mir-oVAX  ->  50  , 

Mar  :nto*h  «>  15  )  )  , 

B_SY-:TFM  «*>  (  300,  400, 

<  5000,  2000,  1000,  250  )  , 

(  45,  20  >  )  )  ; 

end  9ampie__structure  ,* 

An  integer  dump  of  a  message  containing  thiB  data  structure  as 
initialized  would  be  as  follows: 

0)  100 

1)  200 

2)  1000 

3)  900 

4)  200 

5)  50 
C)  50 

7)  15 

8)  300 

9)  400 

10)  5000 

11)  2000 

12)  1000 

13)  250 

14)  45 

15)  20 

At  this  point  enough  information  is  involved  so  that  it  is  already 
difficult  to  determine  what  each  number  represents.  The  format 
of  the  message  displayed  in  context  with  its  Ada  source  code  type 
definition  is  presented  next.  It  includes  an  index  from  the 
beginning  of  the  message  as  a  reference.  The  index  scheme  could 
also  reference  word  addresses  into  the  message,  bit  fields  within 
words,  and  multidimensional  array  positions.  Arrays  of  records 
could  also  bs  presented  In  a  way  that  makes  them  clear  to 
understand. 


The  user  interface  for  this  interactive  recorded  data  examination 
tool  will  be  similar  to  that  of  the  Macintosh,  making  use  of  a 
.‘.ouse,  windows,  and  pull-down  menus. 

By  using  the  mouse  to  select  a  recorded  object,  the  user  will  be 
able  to  perform  operations  on  the  data,  and  will  be  able  to 
investigate  attributes  of  the  object.  One  of  the  more  useful 
features  of  the  tool  is  the  trace  back  of  data  types  to  their 
primitive  type  structure.  If  the  user  were  to  select  the  object 
“DEVICES’*  to  be  operated  upon  using  a  definition  traceback 
operation,  the  following  relevant  information  would  be  displayed: 


typ*  [PERIPHERALS]  is 
(  DISK_CAP  , 

SHARED_RAM  , 

NODES  , 

PRINTERS  )  ; 

typ*  IcffllF  .t'gURAT  I  ON  1  i*  array  ( {PERIPHERALS] )  of 
INTEGER  r.Tnge  0  .  .  10_000  ; 

type  SYSTEM  RECORD  is  record 

PRIMARY  ID,  SECONDARYID  :  LAN  NODE  ID  ? 
f DEVICES T  :  I CONF I GUPsAT IQNJ  ; 

CPU_LEFT  :  NETWORK  ; 

end  record  ? 


It  is  assumed  that,  in  moat  caaea,  a  message  data  structure  has  the 
aame  definition  in  the  aender  and  receiver.  When  that  ia  not  the 
caae,  a  layer  of  deciaion  making  ia  involved  where  the  user 
specifies  this  context. 

Conclusion 

This  paper  explains  how  the  generics  feature  of  the  Ada  language 
can  be  used  to  solve  a  data  reduction  configuration  management 
problem  that  ia  typical  of  many  large  scale  eyetema.  What  is 
unique  about  this  method  ia  the  use  of  a  tool  to  automatically 
generate  the  declarations  of  instantiations  of  the  generic  proce 
dures,  baaed  on  identi  fication  and  decomposition  of  the  recordable 
data  structures. 
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A  METHOD  of  translating  functional  requirements 

FOR  OBJECT-ORIENTED  DESIGN 
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Vcrlynda  Dobbs 


Wright  Stale  University 


ABSTRACT 

The  uk  of  Object-Oriented  Design  method*  for  DoD  system* 
developed  In  Ada  present*  a  number  of  challenges.  One  of 
the  most  critical  is  the  difficulty  of  maintaining  traceability 
between  functional  requirements  and  an  object-oriented 
design.  This  paper  presents  a  forms-based  methodology 
called  Functional  Requirements  Translation  (FRT),  which  can 
be  used  as  a  framework  for  translating  functional 
specifications  into  a  set  of  object  requirements.  Each  require¬ 
ment  is  documented  on  a  Requirement  Translation  Sheet 
(RTS)  and  is  translated  to  a  set  of  objects,  operations,  and 
access  links  between  objects,  which  are  necessary  to  satisfy 
the  requirement.  These  object  requirements  arc  then  com¬ 
bined  from  all  of  the  RTSs  onto  Object  Requirement  Sheets 
(ORSs).  Each  ORS  documents  the  operations  and  access 
link*  of  a  single  object  and  contains  references  back  to  the 
individual  RTSs  which  generated  them.  This  method  pro¬ 
vides  traceability  in  both  directions  of  the  translation  and  can 
be  used  to  identify  unsatisfied  requirements  and  produce  good 
detailed  object  designs. 


1.  INTRODUCTION 

The  U.S.  Department  of  Defense  (DoD)  has  developed  and 
promoted  the  Ada  programming  language  in  an  attempt  to 
lessen  the  impact  of  the  software  crisis  being  brought  on  by 
the  increasing  complexity  of  software  systems.  Ada  enforces, 
or  at  least  suppons,  basic  principles  of  good  software 
engineering  such  as  abstraction,  information  hiding,  and 
modularity .  These  principles  are  brought  together  nicely  in  a 
design  methodology  called  Object-Oriented  Design  (OOD), 
proposed  by  Booch[4],  In  OOD,  software  systems  are 
decomposed  based  upon  abstract  representations  of  objects  in 
the  problem  space.  This  differs  a  great  deal  from  more 


common  approaches  of  decomposing  systems  into  functions. 
For  a  basic  introduction  to  the  principle:  of  OOD,  the  reader 
is  referred  to  (3). 

But  OOD,  as  presented  by  Booch,  is  only  a  design  and 
implementation  approach.  The  first  edition  of  his  book  docs 
present  an  informal  requirement*  analysis  approach  based 
upon  the  work  of  Abbot  ( 1),  but  he  never  claims  that  it 
should  take  the  place  of  a  formal  requirements  analysis.  To 
avoid  further  confusion,  it  was  left  out  of  the  second  edi¬ 
tion^].  So  basic  OOD  provides  no  support  for  requirements 
analysis  or  maintenance  of  requirements  traceability  to  the 
design. 

BccauK  of  this,  Booch  and  other  researches  have  sug¬ 
gested  the  uk  of  established  analysis  methods  such  as  Struc- 
tend  Analysis(9),  JSD(  13.16),  and  VDM[12).  These 
methods  can  be  very  useful  for  clarifying  system  require¬ 
ments  and  developing  structured  requirement  documents,  but 
they  do  not  completely  solve  the  problem  of  requirements 
traceability.  Data  How  analysis,  for  example,  produces  a 
structured  set  of  functional  requirements,  each  of  which  may 
bo  satisfied  by  a  complex  Kt  of  objects,  operations,  and 
object  visibility.  The  difficulties  of  using  data  flows  with 
OOD  have  been  great  enough  for  at  least  one  DoD  contractor 
to  abandon  OOD  complctely(6).  The  problem  is  less  pro¬ 
nounced  with  VDM  and  JSD,  since  the  requirements  they 
produce  contain  more  information  about  the  behavior  of 
problem-space  objects. 

The  difficulties  of  maintaining  requirements  traceability 
with  OOD  are  compounded  by  the  way  the  DoD  does  busi¬ 
ness.  The  development  specifications  for  DoD  systems  are 
functional  and  are  not  usually  subjected  to  any  formal 
requirements  analysis  techniques.  Some  software  developers 
have  applied  Structured  Analysis  to  formalize  specifications 
before  proceeding  with  design,  but  ultimately  the  sys'em 
must  be  tested  for  compliance  with  the  original  requirements. 

If  DoD  software  developers  are  to  take  maximum 
advantage  of  the  software  engineering  features  of  Ada,  some 
method  of  maintaining  functional  requirement  traceability  to 
OOD  must  be  developed.  This  paper  presents  a  structured, 
forms-based  methodology  for  translating  functional  system 
requirements  into  object  requirements,  while  maintaining  tra¬ 
ceability  between  them.  It  is  flexible  enough  to  work  with 
many  different  types  of  requirements,  and  it  docs  not  enforce 
any  particular  design  strategy  (other  than  object-oriented 
decomposition).  It  is  specifically  intended  for  uk  on  DoD 
systems  implemented  in  Ada. 
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2.  THE  TRACEABILITY  GAP 


OperjnamcfParJ  ;Type,  ParJl:Type)  =>  Return  J ;Type. 


We  cm  tee  that  there  is  a  jap  between  requirements  analysis 
methods  which  produce  functionally  decomposed 
specifications,  and  OOO,  which  seeks  to  develop  a  design 
decomposed  into  objects.  Some  software  designers  Have 
found  that  the  simplest  way  to  deal  with  this  problem  is  to 
review  the  functional  specifications,  then  press  on  with  OOD 
and  hope  all  of  the  requirements  are  satisfied  by  the  final 
design.  Another  approach  is  to  assume  that  each  function 
called  out  in  the  specification  corresponds  to  an  operation  on 
some  object;  the  concept  of  an  object  is  used  like  glue  to 
hold  a  group  of  related  functions  together.  Using  this 
approach,  it  is  difficult  to  produce  a  design  which  models  the 
real  world  problem.  More  formal  approaches,  such  as  SOL's 
Abstraction  Analysis[!8),  have  been  suggested,  but  exh 
seems  to  assume  that  there  should  be  a  simple  method  of 
convening  functional  requirements  into  object-oriented 
designs,  similar  to  the  methods  used  to  convert  structured 
data-flow  diagrams  into  structured  designs.  These  approaches 
ignore  the  fact  that  a  good  object-oriented  design  requires 
information  about  the  real  problem  which  may  not  exist  in 
the  functional  requirements.  The  translation  of  functional 
requirements  must  remain  a  creative  human  task;  when  using 
OOD,  the  software  developer  must  design  with  the  real  prob¬ 
lem  in  mind,  choosing  objects  which  best  model  the  problem 
space. 


3.  OBJECT  REQUIREMENTS 

A  method  is  needed  for  maintaining  requirements  traceability 
between  functional  requirements  and  OOD.  The  methodology 
presented  in  this  paper  is  based  upon  the  translation  of  func¬ 
tional  requirements  into  object  requirements  which  cm  then 
be  easily  traced  to  the  design.  The  information  which  must 
appear  in  an  object  requirement  is  the  object  name,  state 
description,  and  definitions  of  operations  and  access  links.  In 
addition,  each  object  is  categorized  as  cither  an  abstract  state 
machine  (ASM),  or  an  abstract  data  type  (ADT)[5]. 

Object  names  are  text  strings  which  uniquely  identify 
objects.  They  arc  used  throughout  the  methodology  to  refer¬ 
ence  objects.  Legal  Ada  identifiers  should  be  used  to  name 
objects  to  make  implementation  easier. 

At  object's  state  description  provides  an  English 
descripion  of  what  the  object  is  meMt  to  represent  and  its 
range  of  possible  states.  Only  the  state  information  which  is 
in  some  way  accessible  to  other  objects  through  operations 
should  be  presented. 

The  operations  on  an  object  are  specified  formally  with 
m  operation  name,  parameter  objects,  and  returned  objects. 
All  parameters  are  assumed  to  be  passed  as  values  to  the 
operation,  so  all  information  provided  by  the  operation  is  in 
the  returned  objects  (implemented  in  Ada  as  either  values  of 
functions,  access  types,  or  ‘out*  parameters).  An  English 
description  of  each  operation  can  also  be  provided,  although 
none  are  used  in  this  paper.  The  format  used  to  specify 
operations  looks  like  this: 


Each  object  requirement  must  also  include  the  names  of 
other  objects  which  it  must  access  to  define  its  state  and  per¬ 
form  its  operations.  These  access  links  represent  visibility 
from  one  object  to  all  of  the  operations  of  another  object. 
Other  researchers  have  suggested  that  the  links  between 
objects  should  include  a  declaration  of  which  specific  opera¬ 
tions  are  accesscd(2).  Some  have  even  suggested  that  exh 
operation  should  have  a  separate  set  of  links  to  the  operations 
on  other  objects  which  it  acccsscs(18).  Although  these 
methods  may  provide  a  more  detailed  representation  of  con¬ 
trol  within  the  object  structure,  there  is  no  easy  way  to 
implement  such  limited  visibility  in  Ada.  Since  FRT  is 
specifically  intended  to  support  OOD  with  Ada,  a  simple 
object- to-oltject  link  is  used.  This  is  also  the  approxh  used 
by  Booch[3,5)  and  BuhrfSj. 

An  object  requirement  for  a  television  set  (apparently 
with  automatic  color  and  contrast  adjustment)  is  shown 
below.  The  operations  require  no  explanation;  based  upon 
the  state  description,  the  purpose  of  exh  is  obvious.  To  pro¬ 
vide  a  picture,  the  television  must  receive  a  signal,  so  this  is 
not  a  complete  model.  However,  it  docs  show  the  basic  for¬ 
mat  of  M  object  requirement. 


Object  Name: 
State  Description: 


Operations: 


Access  Links: 


Tclcvision_Sel 

The  state  of  a  Television_Sct  consists 
of  the  cluutnel  it  is  tuned  to,  and  it's 
on/off  slate. 

Tum_On. 

TumJXT. 

Changc_ChMnel(To_ChMnel:ChMncl). 

Gct_Current_Channil»> 

Cunent_Channcl:Chnnncl. 

Picture_Tubc 

Tuner 

Electrical  ..Outlet 
Channel 


4.  CAPABILITIES  OF  METHODOLOGY 

A  formal  methodology  for  bridging  the  traceability  gap 
should: 

a.  Support  Generation  of  object  requirements  front 
functional  requirements 

b.  Provide  Identification  of  unsatisfied  functional 
requirements 

c.  Provide  Identification  of  unnecessary  object 
requirements 

d.  Be  as  automated  as  possible. 
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The  methodology  must  support  the  requirements  analyst 
while  object  requirements  are  being  developed.  As  stated 
previously,  this  does  not  mean  it  should  automatically  gen* 
crate  the  objects,  but  it  should  provide  a  structured  approach. 
The  methodology  should  be  useful  with  both  functional 
English  teat  requirements  and  products  of  structured  require¬ 
ments  analysis  tcchniques(9]. 

If  all  of  the  objects  and  operations  necessary  to  satisfy  a 
functional  requirement  exist  in  the  current  set  of  object 
requirements,  we  can  consider  it  to  be  satisfied.  The  metho¬ 
dology  must  provide  the  capability  to  easily  identify  those 
functional  requirements  which  arc  not  satisfied  in  this  con¬ 
text.  This  capability  must  be  available  at  any  point  during 
the  translation  of  functional  requirements  to  object  require¬ 
ments. 

If,  for  some  reason,  object  requirements  have  been  gen¬ 
erated  which  are  not  traceable  to  a  functional  requirement, 
the  methodology  must  provide  the  capability  to  identify  them 
as  unnecessary.  This  capability  becomes  more  important 
when  the  design  must  change  in  response  to  changes  in  the 
system  requirements. 

In  their  final  report  for  the  Ada  Simulator  Validation 
Program(20],  Bunck,  Inc.  points  out  the  complex  relation¬ 
ships  which  can  exists  between  functional  requirements  and 
objects  in  an  object-oriented  design.  They  go  on  to  suggest 
that  "Manual  methods  of  tracking  requirements  are 
insufficient  for  handling  the  large  number  of  requirements 
and  objects  needed  for  'a  simulator."  Since  we  would  also 
like  a  method  which  can  scale  up  for  use  on  large  software 
projects2,  we  should  heed  this  advice  and  identify  a  metho¬ 
dology  which  can  be  automated.  The  methodology  presented 
in  this  paper  is  being  applied  manually  to  prove  its  concept, 
but  in  the  future  it  will  be  supported  by  an  automated  tool. 


5.  FUNCTIONAL  REQUIREMENTS  TRANSLATION 

The  methodology  we  are  proposing  is  Functional  Require¬ 
ments  Translation  (FRT).  It  provides  a  flexible  approach  for 
maintaining  requirements  traceability  while  an  object-oriented 
design  is  being  developed  from  functional  specifications.  FRT 
will  be  presented  here  as  a  manual  method  which  meets  three 
of  the  requirements  listed  previously.  The  fourth  require¬ 
ment,  that  the  methodology  be  automated,  will  be  met  by 
developing  a  tool  to  provide  the  necessary  record  keeping 
and  reports.  When  using  FRT,  a  requirements  analyst,  with 
knowledge  about  the  problem  space  and  the  object  require¬ 
ments  already  defined,  can  translate  each  individual  func¬ 
tional  requirement  into  a  set  of  objects,  operations,  and 
access  links  which  will  satisfy  it.  These  object  requirements 
are  combined  incrementally  to  produce  the  set  of  objects 
needed  to  satisfy  all  system  requirements.  In  the  process,  tra¬ 
ceability  to  the  functional  requirements  is  maintained  for  each 
individual  object,  operation,  and  access  link. 

2  Flight  simulators  are  typicalb  100,000  to  500,000  lines 
of  code 


Functional  Requirements  Translation  is  designed  to  track 
complex  relationships  between  functional  requirements,  per¬ 
formance  requirements,  objects,  operations,  access  links,  and 
derived  object  requirements.  It  is  built  on  the  recognition 
that  a  requirements  analyst  must  perform  a  mental  transfor¬ 
mation  of  the  functional  requirements  back  to  the  problem 
space  in  Older  to  generate  a  good  object-oriented  design.  It 
will  also  support  simplified  approaches  to  translating  the 
requirements,  such  as  a  one-to-one  mapping  of  functional 
requirements  to  operations. 

Two  forms  are  used  in  FRT:  the  Requirement  Transla¬ 
tion  Sheet  (RTS),  and  the  Object  Requirement  Sheet  (ORS). 
The  completed  RTSs  and  ORSs  are  the  main  products  of  the 
methodology,  but  others,  such  as  complete  object  diagrams,  a 
Master  Requirements  List,  and  a  Master  Objects  List  can  be 
generated.  Each  RTS  documents  one  functional  or  perfor¬ 
mance  requirement  and  its  translation  to  objects,  operations, 
and  access  links.  Each  ORS  documents  a  single  object,  its 
operations,  access  links,  and  the  functional  and  performance 
requirements  to  which  each  is  traceable. 

An  RTS  consists  of  a  header,  a  body,  and  an  optional 
object  diagram.  A  completed  RTS  is  shown  in  Figure  I.  The 
header  contains  a  title  for  the  requirement,  an  alpha-numeric 
identification,  the  requirement  type  (either  functional  or  per- 
formance),  a  description  which  could  just  be  the  actual  text 
of  the  requirement,  and  the  status  of  .he  requirement.  The  ID 
number  is  a  unique  identifier  for  the  requirement,  either  taken 
directly  from  a  specification  paragraph  number  or  the 
numbering  of  nodes  in  a  dau  flow  diagram.  The  ID  number 
should  also  indicate  the  requirement's  source  document 
(specification,  change  proposal,  correspondence).  The  status 
of  a  requirement  should  be  untranslated,  translated,  or  com- 
bined.  The  meaning  of  these  will  become  apparent  as  the 
FRT  process  is  explained.  The  body  of  the  RTS  contains 
one  entry  for  each  object  needed  to  satisfy  the  requirement, 
and  each  object  entry  contains  definitions  for  the  specific 
operations  which  are  needed,  and  a  list  of  other  objects 
which  must  be  accessed.  Each  RTS  can  also  contain  an 
object  diagram,  which  is  a  graphic  representation  of  the 
object  entries.  Only  the  objects,  operations,  and  access  links 
necessary  to  satisfy  the  requirement  should  appear  on  it. 
Except  for  some  minor  differences,3  the  object  diagrams  in 
this  paper  follow  the  conventions  established  by  the  Goddard 
Space  Flight  Center,  Software  Engineering  Laboratory!  18). 


i  SEL  uses  the  term  Provides  instead  of  Operations,  and 
uses  instead  of  Access.  SEL  Uses  entries  also  list  the 
specific  operations  used,  not  just  the  object. 
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REQUIREMENT  TRANSLATION  SHEET 
HEADER 


TITLE:  Client  Information  on  Reports 
ID  NUMBER:  spcr.3.2.2 
TYPE:  Functional 

DESCRIPTION:  The  client's  name  and  address  must  appear 
at  the  top  of  all  reports. 

STATUS:  Translated 


BODY 


OBJECT:  General Joumal.Hc  port 
ACCESS  LINK:  Client 
ACCESS  LINK:  Person.Namc 
ACCESS  LINK:  Address 

OBJECT:  General.  Ledjer.Rcport 
ACCESS  LINK:  Client 
ACCESS  LINK:  Person.Namc 
ACCESS  LINK:  Address 

OBJECT:  Client 

OPERATION:  Name(Of.Client :  Client)  ■>  CHcnt.Namc :  Person.Namc. 
OPERATION:  Addrcss(Of.Client :  Oiem)  •>  Client. Address  :  Address. 
ACCESS  LINK:  Person.Namc 
ACCESS  LINK:  Address 

OBJECT:  Person.Namc 

OPERATION:  Prim.on_RcportfIhc.Name :  Person.Namc). 

OBJECT:  Address 

OPERATION:  IYtot_on.Rcp(jrtCrhc_Namc :  Person.Namc). 


OBJECT  DIAGRAM 


A  completed  ORS  Is  shown  in  Figure  2.  It  consists  of  a 
header,  a  body,  and  an  optional  object  diagram.  The  ORS 
header  conuins  the  object  name,  type  (ASM  or  ADT),  level, 
and  state  description.  These  have  all  been  described  already, 
with  the  exception  of  object  levels,  which  will  be  explained 
later.  The  ORS  body  contains  one  entry  for  each  operation  or 
access  link  the  object  possesses,  and  each  entry  contains  the 
identification  number  of  the  functional  and  performance 
requirements  lo  which  the  entry  iicm  (operation  or  access 
link)  can  be  traced.  Operation  entries  must  define  the 
operation’s  parameters  and  returned  values,  and  access  link 
entries  musi  name  the  accessed  object.  Entries  which 
represent  derived  operations  or  access  link  requirements 
should  reference  (he  objects  which  use  them.  ORSs  can  also 
contain  an  object  diagram  which  represents  the  object,  iis 
operations,  and  any  access  links  to  other  objects. 


OBJECT  REQUIREMENT  SHEET 
HEADER 


NAME:  Client 
TYPE:  ADT 
LEVEL:  unknown 

STATE  DESCRIPTION:  Client  It  an  abstract  data  type  which  manages 
client  Information.  It  contains  the  client's  name,  address, 
and  fiscal  year  structure. 


BODY 


OPERATION:  Name(Of_Client :  Client)  ■>  Clicnt_Namc :  Person.Namc. 
FUNCTIONAL:  spec.3.2.2 

OPERATION:  AddressfOf.CIient :  Oiem)  ■>  Cliem.Aiklrcss :  Address. 
FUNCTIONAL:  spec.3.12 

OPERATION:  EstaNish.Rscal.YearfThe.Client :  Client). 
FUNCTIONAL:  specJ.U.  cocr,IZ3 


ACCESS  LINK:  Person.Namc 
FUNCTIONAL:  specJ.Z2 

ACCESS  UNK:  Address 
FUNCTIONAL:  specJ2.2 

ACCESS  UNK:  Fiseal.Year 
FUNCTIONAL:  s^cj.1.4 

ACCESS  UNK:  Calendar.Month 
FUNCTIONAL:  specJ.U 
PERFORMANCE:  spec.5.2 


Opowlom:  Opcmionc 

ftirt.eojtrport  Ptint.M.Krrm 


Figure  1.  Completed  RTS 
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5.1.  CLASSIFY  REQUIREMENTS 

The  purpose  of  this  step  is  to  organize  system  requirements 
«nd  classify  them  a $  functional  or  performance.  The  require* 
ments  must  be  classified  because  functional  and  performance 
requirements  are  translated  differently,  during  separate  steps 
of  the  FRT  process.  During  the  Classify  Requirements  step, 
an  RTS  is  created  for  each  system  requirement  and  the 
requirement  ID  number  structure  is  established.  It  may  also 
be  desirable  to  break  a  large  system  into  subsystems  if  simple 
interfaces  exist.  If  this  is  done,  the  requirements  should  be 
divided  accordingly  and  FRT  should  be  applied  separately  to 
each  subsystem.  No  differentiation  is  made  between  hardware 
and  software  requirements  during  the  FRT  process;  this  is  left 
as  a  design  task. 

A  Requirements  Translation  Sheet  is  generated  for  each 
requirement,  but  only  the  following  header  information  is 
filled  in: 

Title 

ID  Number 

Type  (Functional  or  Performance) 

DcscriptionfTcxt 

Status 

The  body  of  the  RTS  will  be  filled  out  when  the  requirement 
is  translated  into  object  requirements,  For  easy  reference, 
RTSs  should  be  filed  by  their  ID  numbers.  It  may  also  be 
useful  to  keep  a  Master  Requirements  List  showing  the  ID 
number,  title,  type,  and  status  of  each.  Every  requirement 
should  begin  with  a  status  of  untranslated. 

5.1  IDENTIFY  PRELIMINARY  OBJECTS 

During  this  step,  informal  methods  are  used  to  define  a  ston¬ 
ing  set  cf  objects,  operations,  and  access  links.  This  estab¬ 
lishes  a  top-level  structure  for  the  object  requirements  and 
anchors  representations  of  problem-space  objects  which  may 
not  be  clearly  represented  in  the  functional  requirements. 
This  step  can  also  provide  a  common  vocabulary  for  a  group 
of  analysis  working  on  the  same  translation;  identifying  a 
preliminary  set  of  objects  may  help  prevent  the  creation  of 
multiple  objects  with  different  names  which  represent  the 
same  problem-space  entity,  or  multiple  ASM  objects  which 
could  have  been  a  single  ADT  object. 

A  number  of  methods  for  identifying  potential  objects 
have  been  suggested  in  the  OOD  literature.  Although  Grady 
Booch  no  longer  supports  the  Informal  Description  as  a  for¬ 
mal  design  method,  this  is  one  place  where  it  could  be  use¬ 
ful.  Top-level  descriptions  of  the  system  would  probably  be 
good  sources  of  preliminary  problem-space  objects,  and  the 
names  given  to  items  in  a  data-flow  diagram  could  also  be  a 
good  source. 

Each  preliminary  object  is  established  by  filling  in  at 
least  the  object  name,  type  (ASM  or  ADT),  and  a  partial 
state  description  on  an  Object  Requirement  Sheet.  If  possible, 
the  ORS  header  can  be  filled  in  completely  and  a  set  of 


operations  and  access  relationships  can  be  defined  in  the 
body  of  the  ORS.  If  a  Master  Objects  List  is  used,  the  name 
and  type  of  each  preliminary  object  should  be  added  to  it. 
Until  each  object,  operation,  or  access  link  is  assigned  tracea¬ 
bility  back  to  a  functional  requirement  or  another  object,  it  is 
considered  unnecessary.  Any  preliminary  objects  which  are 
stilt  unnecessary  after  translation  of  all  functional  require¬ 
ments  and  identification  of  all  derived  objects  should  be 
examined  as  candidates  for  deletion. 


5.3.  TRANSLATE  FUNCTIONAL  REQUIREMENTS 

An  analyst  translates  a  functional  requirement  into  object 
requirements  by  identifying  a  set  of  objects,  operations,  and 
access  links  which  will  satisfy  it.  If  possible,  these  objects 
should  be  taken  from  the  basic  set  of  objects  already  esta¬ 
blished  on  ORS.-.  An  existing  object  may  not  have  the  exact 
operation  needed  or  an  access  link  to  a  certain  object,  but 
identifying  these  during  translation  will  ensure  they  become 
pan  of  the  object  requirement  in  the  future.  An  example 
requirement  for  an  accounting  system  is  shown  below,  along 
with  the  objects,  operations,  and  access  rights  to  which  it 
might  translate. 

REQUIREMENT 

The  system  shall  allow  the  user  to  establish  a  different  fiscal 
year  staning  month  for  each  client. 


TRANSLATION 

OBJECT:  Accountant 
ACCESS  LINK:  Client 

OBJECT;  Client 

OPERATION:  &!abUsh_Fiscal_Yearfnie_aient:aienO 
*>  The_Client;Clicnt. 

ACCESS  LINK:  Fneal.Year 
ACCESS  LINK:  Calendw.Month 

OBJECT:  Rica!_Year 

OPERATION:  Create  ->  N«w_Fiscal_Year :  Fiacal^Year. 
OPERATION:  Set_FmLMonth<Thc_Fi»cal_Ycar :  Fiacal.Year, 
Fint_Month :  Cakndar_Month) 

■>  The_Fi>cal_Ye*r :  Fiacal.Year. 
ACCESS  LINK:  Calendar_Month 

OBJECT:  Calendar_Monih 

Again,  both  Grady  Booch’s  Informal  Description 
method  and  the  terminology  used  in  a  data-flow  diagram  can 
help  identify  the  needed  objects.  But,  existing  objects  should 
be  checked  before  generating  new  ones. 
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Required  objecii  are  documented  on  the  Requirement 
Translation  Sheet  by  making  an  entry  for  each  in  the  body. 
An  object  diagram  showing  three  objects  can  also  be  added. 
Each  RTS  entry  should  contain  the  definition  of  one  object's 
operations  and  a  list  of  its  access  links  to  other  objects. 
After  alt  necessary  entries  have  been  made,  the  status  of  the 
RTS  should  be  changed  to  translaud. 

It  is  not  necessary  to  define  the  operations  of  the  lowest 
level  objects  (the  ones  which  do  not  access  others).  In  fact, 
if  their  operations  were  defined,  they  would  require  access  to 
the  objects  they  pass  as  parameters  or  return.  This  would 
require  every  translation  to  define  objects  and  operations 
down  to  the  most  basic  objects  already  defined  by  the  imple¬ 
mentation  language  (Integer,  float,  duration  for  Ada).  In  the 
example  above,  Cakndar_Month  could  have  defined  opera¬ 
tions  such  as: 

OPERATION:  Create(The_Month:MotUh JN  umber) 

*>  NtwJ4onlk:CalendarJdonlk , 

But  this  would  require  another  object,  Month.Number,  which 
is  accessed  by  Calendar_Month.  To  keep  translations  simple, 
they  should  contain  only  those  objects  which  directly  relate 
to  the  requirement.  Lower  level  objects  which  just  support 
the  translation  should  be  defined  later  as  derived  require¬ 
ments. 


5.4.  COMBINE  OBJECT  REQUIREMENTS 

During  this  step  of  FRT,  the  translations  on  the  RTSs  are 
combined  to  form  object  requirements.  Each  object  require¬ 
ment  on  an  RTS  is  used  to  generate  a  new  Object  Require¬ 
ment  Sheet  er  update  an  existing  one,  and  traceability  to  the 
functional  requirement  is  maintained.  This  step  should  occur 
whenever  a  group  of  completed  RTSs  is  available.  This  will 
make  any  new  objects  immediately  available  to  the  analysts 
doing  the  functional  translations. 

Each  object  requirement  on  an  RTS  must  be  transferred 
to  the  ORS  for  that  object.  If  no  ORS  exists,  one  must  be 
created  by  filling  in  the  necessary  header  information.  A 
separate  entry  is  made  in  the  ORS  body  for  each  operation  or 
access  link  listed  for  that  object  on  the  RTS.  The  ID  number 
from  the  RTS  is  then  added  to  each  of  these  entries  so  that 
each  operation  and  access  link,  can  be  traced  separately  back 
to  it.  If  an  ORS  entry  alrcrdy  exists  for  an  operation  or 
access  link,  the  functional  requirement  ID  number  must  still 
be  added.  This  means  one  operation  or  access  link  can  be 
traceable  to  more  than  one  functional  requirement.  After 
transferring  the  object  information  from  the  RTS  to  the 
ORSs,  the  new  objects  should  be  added  to  the  Master  Objects 
List  (if  one  is  used),  and  the  sutus  of  the  RTS  should  be 
changed  to  combined. 

After  updating  the  ORSs  for  each  of  the  object  entries 
on  the  RTS,  the  analyst  should  check  for  access  loops.  Each 
new  access  link  which  was  added  to  the  set  of  objects  could 
potentially  have  completed  a  loop  of  access  links.  A  path  of 
access  links  passing  from  an  added  or  updated  object, 


through  other  objects  and  their  access  links,  back  to  thfe  start¬ 
ing  object,  cannot  be  directly  implemented  in  Ada.  When  a 
loop  is  found,  it  must  be  broken  by  changing  at  least  one 
requirement  translation.  One  possible  solution  is  the  addition 
of  a  ‘communication*  object  as  shown  in  Figure  4.  If 
object_A  and  object_B  must  send  messages  to  each  other, 
they  should  not  access  each  other  •  both  should  access  a 
separate  message  object,  and  if  possible,  the  object  used  to 
break  the  loop  should  represent  a  problem  space  object.  The 
methodology  presented  in  this  paper  is  currently  manual,  so 
the  recommended  method  of  searching  for  these  loops  is 
inspection  by  the  analyst;  no  formal  algorithm  is  presented. 


V 


Figure  4.  Breaking  Access  Cycles 


Object  level  numbers  should  be  updated  periodically 
during  the  process  of  combining  RTSs.  The  level  number  of 
any  object  which  is  not  accessed  by  any  other  object  is  zero. 
The  level  of  any  other  object  is  one  deeper  than  the  deepest 
level  object  which  accesses  it  (greater  numbers  represent 
deeper  levels).  Figure  5  shows  the  access  structure  of  a  group 
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of  object*  and  their  resulting  level  numbers.  Level  number* 
provide  a  clear  hierarchical  structure  and  can  be  used  to 
define  subset*  of  object*  such  as  ‘‘all  object*  down  to  level  3' 
or  "Objcct_A  and  all  objects  it  accesses  down  to  level  3",  It 
is  probably  not  a  good  idea  to  update  level  numbers  after 
each  RTS  i*  added,  because  a  change  in  the  way  one  object 
is  accessed  may  change  the  level  number  of  many  other 
object*.  At  the  very*  least,  however,  the  level  numbers  of 
objects  should  be  calculated  after  the  last  RTS  is  combined. 


Figure  5.  Level  Number  Example 


5.5.  IDENTIFY  DERIVED  REQUIREMENTS 

The  set  of  object  requirements  is  not  yet  complete  when  all 
of  the  system  requirements  have  been  translated.  Additional 
objects  and  operations  will  have  to  be  added  to  support  the 
existing  objects;  these  are  derived  object  requirements. 
Derived  objects  may  have  to  be  added  for  several  reasons. 
First,  the  translation  may  not  have  produced  all  of  the  top 
level  objects  necessary  to  provide  a  clear  hierarchical  struc¬ 
ture  for  the  system/  Second,  new  operations  and  access  links 
may  have  to  be  added  to  existing  objects.  It  is  certainly  not 
reasonable  to  expect  an  analyst  to  identify  all  needed  opera¬ 
tions  during  the  initial  translation.  Many  of  these  require¬ 
ments  will  not  be  apparent  until  detailed  design  of  individual 

4  A  good  indication  of  this  is  the  presence  of  more  than 
one  level  zero  object. 


operation*  are  produced.  Finally,  additional  tow-lcvcl  objects 
may  be  needed  to  support  the  existing  object*.  If  possible, 
these  objects  should  represent  deeper  level*  of  the  problem 
space, ‘but  at  some  point  it  may  be  necessary  to  define  purely 
solution  space  object*  such  as  generic  data  structure*. 

A  new  ORS  should  be  created  for  each  derived  object 
requirement  (unless  it  was  already  created  during  the 
identification  of  preliminary  objects  or  combination  process). 
Alt  of  the  header  information  should  be  filled  in  and  entries 
made  in  the  ORS  body  for  each  of  the  derived  object’s 
operation*  and  access  links.  The  derived  requirement  entries 
are  completed  by  adding  the  name  of  the  existing  objects 
which  require  the  existence  of  the  operation  or  access  link. 
This  means  derived  object  requirements  are  only  traceable  to 
other  objects;  a  derived  requirement  becomes  unnecessary 
when  it  cannot  be  traced  to  an  existing 
necessary  object.  Each  derived  object  should  also  be  added 
to  the  Master  Objects  List. 


5.6.  EST/  8L1SII  TRACEABILITY  TO 

PERFORMANCE  REQUIREMENTS 

During  this  step,  the  requirements  analyst  determines  the 
scope  of  each  performance  requirement  and  updates  its  RTS 
and  the  associated  ORSs.  Performance  requirements  are 
translated  in  much  the  same  way  as  functional  requirements, 
using  the  same  forms.  The  objects,  operations,  and  access 
links  subject  to  the  constraints  of  the  performance  require¬ 
ment  are  entered  on  its  RTS,  and  the  performance  require¬ 
ment  ID  number  is  added  to  their  ORS  entries.  The  perfor¬ 
mance  requirement  ID  numbers  in  an  ORS  entry  should  be 
set  apart  from  the  functional  requirement  ID  numbers  because 
they  have  different  effects  on  the  traceability  of  the  object. 
For  example,  traceability  to  a  performance  requirement  alone 
does  not  mean  an  operation  or  access  link  is  necessary.  Per- 
fomuncc  requirements  do  not  generate  object  requirements, 
they  just  constrain  their  behavior. 


6.  APPLYING  THE  METHODOLOGY 

FRT  has  the  flexibility  to  support  many  different  approaches 
to  OOD,  We  can  look  at  two  simple  approaches  which  have 
been  used,  then  recommend  an  approach  which  combines  the 
strong  points  of  both.  The  recommended  approach  is  more 
complex,  but  the  added  complexity  can  be  handled  by  using 
FRT,  and  it  can  generate  a  bener  object-oriented  design. 

One  simple  form  of  OOD  involves  the  separation  of 
requirements  traceability  and  design.  The  system  designers 
look  over  the  system  requirements  and  then  begin  identifying 
objects  and  performing  the  design.  No  requirements  tracea¬ 
bility  information  is  maintained.  The  fully  developed  system 
is  then  tested  against  the  original  requirements  and  the 
designers  pray  that  it  meets  them.  Obviously  this  is  an 
extreme  approach  and  is  unacceptable  for  all  but  the  simplest 
pieces  of  software.  However,  if  a  developer  chooses  to  use 
it,  FRT  can  be  of  some  help.  If  the  Identify  Preliminary 
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Objects  step  is  extended  until  the  entire  design  is  complete, 
FRT  effectively  becomes  this  approach.  Designers  who  hap. 
pen  to  know  why  they  are  defining  a  given  object  can  easily 
take  the  time  to  make  some  entries  on  the  RTSs  and  ORSs. 
Not  all  objects  will  be  traceable,  and  not  all  requirements 
will  appear  satisfied,  but  some  traceability  information  is 
better  than  none. 

Another  simple  OOD  method  assumes  a  direct  one-to- 
one  relationship  between  functional  requirements  and  opera* 
tions  on  objects.  Most  applications  of  this  approach  have 
involved  some  front-end  requirements  analysis  using  data 
flow  methods.  Function  nodes  are  translated  directly  to 
operations,  and  objects  are  identified  to  represent  data  stores 
and  data  flows  and  to  g/tre  related  operations  together.  This 
design  method  provides  straightforward  requirements  tracea¬ 
bility,  but  can  only  produce  a  design  which  models  the  prob¬ 
lem  space  if  all  of  the  problem  space  objects  are  present  in 
the  data  flows.  Again,  FRT  can  support  this  approach  if  a 
software  developer  chooses  to  use  it.  The  entire  FRT  process 
would  be  followed,  but  requirement  translations  would  only 
consist  of  a  main  object,  one  operation  on  it,  and  whatever 
objects  it  had  to  access  to  perform  that  single  operation. 

We  recommend  an  approach  to  FRT  which  can  provide 
requirements  traceability  without  sacrificing  a  good  represen¬ 
tation  of  the  problem  space.  After  classifying  all  of  the  sys¬ 
tem  requirements,  they  should  be  reviewed  and  some 
emphasis  should  be  placed  on  establishing  a  good  top-level 
structure  of  preliminary  objects  which  represent  the  problem 
space  There  is  no  real  danger  in  generating  extra  objects;  if 
they  really  are  unnecessary,  FRT  will  eventually  show  it. 
Next,  requirements  should  be  translated  one  at  a  time,  or  in 
small  groups,  then  combined  as  soon  as  possible  with  the 
existing  ORSs.  Analysts  should  feel  free  to  identify  prelim¬ 
inary  or  derived  object  requirements  at  any  time  during  the 
FRT  process. 

A  Master  Requirements  List  and  Master  Objects  List  are 
probably  not  necessary  on  relatively  small  projects  where  it  is 
practical  to  just  flip  through  RTSs  and  ORSs.  If  these  lists 
are  used,  it  must  be  understood  that  they  are  just  a  summary 
of  the  information  on  the  main  forms.  They  should  be 
checked  periodically  to  make  sure  they  are  consistent. 

Object  diagrams  should  be  used  if  the  tools  needed  to 
maintain  them  are  available.  They  provide  a  quick  view  of 
the  object  structure,  and  arc  generally  easier  to  analyze  than 
the  written  object  requirements.  FRT  does  not  prescribe  any 
format  for  a  complete  system  object  diagram,  but  it  is  obvi¬ 
ous  that  it  will  have  to  be  a  hierarchy  of  separate  diagrams.  It 
is  important  to  insure  that  the  object  diagrams  match  the 
information  on  the  ORSs. 


7.  USING  THE  PRODUCTS 

The  primary  products  of  Functional  Requirements  Translation 
are  the  Requirement  Translation  Sheets  and  the  Object 
Requirement  Sheets.  Other,  optional  products  are  the  Master 
Requirements  List,  Master  Objects  List,  and  the  combined 
object  diagrams,  but  these  are  just  alternate  representations  of 


the  data  on  the  RTSs  and  ORSs.  These  products  can  have 
many  different  uses,  but  they  are  mainly  intended  to  support 
the  design  phase,  identify  unsatisfied  requirements,  and  iden¬ 
tify  unnecessary  object  requirements. 

FRT  only  supports  the  translation  of  functional  require¬ 
ments  to  object  requirements.  The  classification  of  object 
requirements  as  cither  hardware  or  software  requirements  (or 
both)  is  left  as  a  design  issue.  Also,  FRT  docs  not  support 
Ada  implementation  decisions.  Each  ORS  can  be  imple¬ 
mented  as  an  Ada  package,  task,  generic,  or  just  a  derived 
type.  Operations  can  be  procedures,  functions,  task  entries, 
or  even  declarations.  Tracing  these  Ada  constructs  back  to 
their  ORS  should  be  straightforward  (especially  if  the  same 
names  arc  used)  and  the  ORS  provides  the  traceability  back 
to  the  original  requirements. 

The  most  Important  use  for  FRT  products,  from  the 
developer's  point  of  view,  should  be  tracing  object  require¬ 
ments  back  to  the  functional  and  performance  requirements 
they  must  satisfy.  This  becomes  a  significant  capability  dur¬ 
ing  the  design  phase,  allowing  the  designer  to  sec  exactly 
what  an  object,  or  a  set  of  objects,  must  accomplish. 

The  generated  RTSs  can  be  used  to  identify  unsatisfied 
requirements.  Any  system  requirement  which  has  no  RTS,  or 
has  an  RTS  with  a  status  other  than  combined,  is  considered 
unsatisfied.  The  translation  of  the  RTS  may  be  complete,  but 
if  it  has  not  been  combined,  the  current  object  structure  may 
not  contain  all  of  the  objects,  operations,  and  access  links 
needed  to  satisfy  it. 

The  ORSs  can  be  used  to  identify  unnecessary  objects, 
operations,  and  access  links.  These  have  no  valid  reason  to 
appear  in  the  system  design,  based  upon  the  functional 
requirements  which  have  already  been  translated.  An  opera¬ 
tion  or  access  link  can  be  considered  unnecessary  if  its  ORS 
shows  no  traceability  back  to  a  functions!  requirement  or 
another  object  requirement.  Any  operation  or  access  link 
which  Is  only  traceable  to  other  unnecessary  objects  is  also 
considered  unnecessary.  Objects  are  unnecessary  only  if  they 
have  no  necessary  operations  or  access  links. 


8.  handling  changing  requirements 

Besides  helping  verify  that  a  design  meets  the  requirements, 
FRT  can  also  help  analysts  and  designers  deal  with  changes 
in  the  requirements.  Most  DoD  system  specifications  change 
frequently,  so  we  must  be  able  to  update  our  set  of  objects  in 
response  to  new,  deleted,  or  modified  functional  or  perfor¬ 
mance  requirements. 

If  a  new  requirement  is  added,  it  must  be  subjected  to 
the  entire  FRT  process.  The  requirement  must  be  classified 
and  documented  on  an  RTS.  If  it  is  a  performance  require¬ 
ment  its  traceability  to  existing  ORSs  must  be  established.  If 
the  requirement  is  functional,  it  must  be  translated  and  its 
translation  must  be  combined  with  existing  ORSs  (possibly 
generating  new  ones).  All  performance  requirements  must  be 
re-evaluated  to  see  if  the  operations  and  access  links  gen¬ 
erated  by  the  new  functional  requirement  are  subject  to  their 
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constraints.  AU  RTSs  and  ORSs  must  be  updated  accord- 

folly- 

If  a  system  requirement  Is  deleted,  Its  RTS  is  destroyed 
and  all  references  to  it  on  ORSs  arc  removed.  Note  that  the 
deletion  of  a  functional  requirement  could  cause  some  objects 
to  become  unnecessary. 

The  most  straightforward  way  to  handle  a  modified 
requirement  is  to  assume  it  was  deleted  completely,  then 
added  under  the  same  ID  number.  It  is  also  possible  to  just 
review  the  existing  RTS  for  the  requirement  and  make  any 
necessary  changes  to  its  translation  and  effected  ORSs. 


9.  FUTURE  IMPROVEMENTS 

There  are  many  ways  FRT  could  be  expanded  and  improved 
in  the  future.  It  is  currently  a  manual  method,  and  coukl  be 
very  cumbersome  for  large  systems.  It  also  provides  very  lit¬ 
tle  direct  support  for  the  design  phase.  Besides  these  two 
major  areas,  there  are  many  other  small  improvements  which 
could  help  m#kc  FRT  more  acceptable  to  developers  of  Ada 
systems. 

The  most  important  future  improvement  in  FRT  is  its 
automation.  This  will  be  accomplished  by  developing  a  tool 
for  the  creation  and  maintenance  of  the  RTSs  and  ORSs. 
Such  a  system  could  easily  generate  Master  Requirements 
Lists  and  Master  Objects  Lists,  and  could  identify  unsatisfied 
requirements  and  unnecessary  objects.  Other  features  which 
could  be  useful  are  the  automatic  combination  of  completed 
RTSs  with  existing  ORSs  and  identification  of  access  loops 
in  the  object  structure. 

FRT  could  also  be  expanded  to  better  support  the  design 
phase.  It  should  allow  the  analyst  or  designer  to  differentiate 
between  hardware  and  software  requirements,  and  it  should 
record  decisions  about  the  Ada  constructs  which  will  be  used 
to  implement  each  object  and  operation.  It  would  also  be 
useful  to  extend  the  object  requirements  to  include  definitions 
of  the  exceptions  handled  and  generated  by  each  object. 

There  are  many  other  improvements  which  could  make 
FRT  more  comprehensive  and  useful.  For  complex  systems 
which  exist  in  many  configuiations,  it  would  be  helpful  to 
have  some  sort  of  version  numbering  facility.  Such  a  system 
could  also  benefit  from  a  better  method  of  tracking  the  source 
of  individual  requirements  (currently  this  information  is  con¬ 
tained  in  the  ID  number).  A  more  complex  improvement,  but 
one  which  has  been  accomplished  on  other  OOD  support 
tools(2],  is  integration  with  a  drawing  tool  which  can  be 
modified  to  support  OOD  and  provide  parsablc  output  to 
FRT. 


10.  CONCLUSIONS 

We  have  introduced  Functional  Requirements  Translation,  a 
methodology  for  translating  functional  requirements  to  object 
requirements  while  maintaining  requirements  traceability.  It 


is  intended  for  use  with  OOD  and  Ada  on  DoD  systems. 
FRT  Is  flexible  and  relatively  simple  to  use,  and  it  can  sup¬ 
port  most  requirements  analysis  methods  and  object 
identification  methods  being  used  with  Ada.  It  is  simple 
because  h  Is  based  around  only  two  form  and  involves  no 
complex  algorithms.  It  allows  the  requirements  analyst  to 
perform  the  translation  with  confidence  that  alt  of  the  system 
requirements  are  being  addressed. 

Researchers  have  addressed  many  different  aspects  of 
applying  OOD  with  Ada,  but  very  few  have  taken  a  practical 
approach  to  maintaining  requirements  traceability.  In  the 
future,  it  is  possible  that  FRT,  with  the  support  of  an 
automated  tool  and  some  enhancements  to  support  the  design 
phase,  will  help  bridge  this  traceability  gap. 
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